Re: Question regarding x86_64 __PHYSICAL_MASK_SHIFT

[Tejun Heo <htejun@gmail.com>]

  Hello, Andi.

Andi Kleen wrote:
> On Tuesday 04 October 2005 21:19, Tejun Heo wrote:
> 
> 
>>  Hmmm.. but, currently
>>
>>* PHYSICAL_PAGE_MASK == (~(PAGE_SIZE-1)&(__PHYSICAL_MASK << PAGE_SHIFT)
>>	== (0xffffffff_fffff000 & (0x00003fff_ffffffff << 12)
>>  	== 0x03ffffff_fffff000
>>  while it actually should be 0x00003fff_fffff000
> 
> 
> Right. Fixed now
> 
> 
>>* PTE_FILE_MAX_BITS == __PHYSICAL_MASK_SHIFT == 46, but only 40bits are
>>available in page table entries.
> 
> 
> The non linear mapping format is independent from the MMU, the number
> is pretty much arbitary, but it is consistent to make it the same as
> other ptes for easier sanity checking.

  Okay, please forgive me if I'm bugging you with something stupid but I 
still don't quite get it.  When using NONLINEAR mapping, pgoff is stored 
to pte to use later when faulting in the page.  Storing and reading 
pgoff are done with the following macros.

#define pte_to_pgoff(pte) \
	((pte_val(pte) & PHYSICAL_PAGE_MASK) >> PAGE_SHIFT)
#define pgoff_to_pte(off) \
	((pte_t) { ((off) << PAGE_SHIFT) | _PAGE_FILE })

  In pte_to_pgoff we're masking pte value with PHYSICAL_PAGE_MASK which 
gives us 34bits with patches applied.  This means that if a pgoff goes 
through pgoff_to_pte and then pte_to_pgoff only 34bits survive.

  sys_remap_file_pages() checks if required pgoff's fit in pte's using 
PTE_FILE_MAX_BITS.

#define PTE_FILE_MAX_BITS __PHYSICAL_MASK_SHIFT

  Which is 46 with patches applied.  Meaning that we could end up 
shoving up value larger than 34bits into pte and losing information when 
reading back (and it's only 16GB!).

  So, IMHO, we should either shrink PTE_FILE_MAX_BITS to 36 or change 
pte_to_pgoff/pgoff_to_pte macros to carry more bits (as pte bits 52-62 
are available, we can shove 46bits easily).

  No?

-- 
tejun