On Mon, Aug 26, 2019 at 08:07:13AM +0530, Anshuman Khandual wrote: > On 08/09/2019 07:22 PM, Matthew Wilcox wrote: > > On Fri, Aug 09, 2019 at 04:05:07PM +0530, Anshuman Khandual wrote: > >> On 08/09/2019 03:46 PM, Matthew Wilcox wrote: > >>> On Fri, Aug 09, 2019 at 01:03:17PM +0530, Anshuman Khandual wrote: > >>>> Should alloc_gigantic_page() be made available as an interface for general > >>>> use in the kernel. The test module here uses very similar implementation from > >>>> HugeTLB to allocate a PUD aligned memory block. Similar for mm_alloc() which > >>>> needs to be exported through a header. > >>> > >>> Why are you allocating memory at all instead of just using some > >>> known-to-exist PFNs like I suggested? > >> > >> We needed PFN to be PUD aligned for pfn_pud() and PMD aligned for mk_pmd(). > >> Now walking the kernel page table for a known symbol like kernel_init() > > > > I didn't say to walk the kernel page table. I said to call virt_to_pfn() > > for a known symbol like kernel_init(). > > > >> as you had suggested earlier we might encounter page table page entries at PMD > >> and PUD which might not be PMD or PUD aligned respectively. It seemed to me > >> that alignment requirement is applicable only for mk_pmd() and pfn_pud() > >> which create large mappings at those levels but that requirement does not > >> exist for page table pages pointing to next level. Is not that correct ? Or > >> I am missing something here ? > > > > Just clear the bottom bits off the PFN until you get a PMD or PUD aligned > > PFN. It's really not hard. > > As Mark pointed out earlier that might end up being just a synthetic PFN > which might not even exist on a given system. And why would that matter?
