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. _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
