On Tue, Jan 22, 2019 at 05:27:29PM -0800, Dan Williams wrote:
On Mon, Jan 21, 2019 at 6:49 PM Wei Yang
> There are two places to calculate npfns in nd_pfn_init(), while they use
> difference size to calculate.
> Use PAGE_SIZE would be more proper for calculation.
No, this would make the kernel have different output based on
PAGE_SIZE. It should be possible for a PAGE_SIZE==64K system to create
a valid info-block for PAGE_SIZE==4K system. This would need to encode
the PAGE_SIZE in the info-block if it were to ever support non-4K
I am confused.
Generally, npfns is used in two functions: nd_pfn_init() and
The code flow looks like this:
npfns = SECTION_ALIGN(trim_size / PAGE_SIZE)
offset = start + npfns * page_struct
npfns = (trim_size - offset) / SZ_4K
nd_pfn->npfns = pfn_sb->npfns
nd_pfn->npfns = (trim_size - offset) / PAGE_SIZE
My questions are:
1. offset = start + npfns * page_struct
This means the number of page struct we reserve in meta-data area is
calculated with PAGE_SIZE page.
But we set pfn_sb->npfns = (trim_size - offset) / SZ_4K, which
means we tell hardware the number of pages is calculated with 4K size.
Would this be a conflict? Or at least we need to reserve more meta-data
area to hold page struct?
2. When mode == PFN_MODE_PMEM and PAGE_SIZE == 64K,
nd_pfn->pfn_sb->npfns is sure to be bigger than nd_pfn->npfns. Because
nd_pfn->pfn_sb->npfns = (trim_size - offset) / 4K
nd_pfn->npfns = (trim_size - offset) / 64K
If we are sure for the final result, why we would like to have this
Another consideration is that a PAGE_SIZE==4K infoblock is compatible
with a PAGE_SIZE==64K system. All that happens is that the memmap
reserve area is oversized and portions go unused. The reverse is not
The oversized memap reserve area is SECTION size aligned? If so, it looks we
took that into consideration when we calculate offset.
Help you, Help me