On Mon, Mar 21, 2016 at 10:03:29AM +0530, Aneesh Kumar K.V wrote: > "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> writes: > > > [ text/plain ] > > On Fri, Mar 18, 2016 at 07:23:41PM +0530, Aneesh Kumar K.V wrote: > >> "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx> writes: > >> > >> > [ text/plain ] > >> > split_huge_pmd() for file mappings (and DAX too) is implemented by just > >> > clearing pmd entry as we can re-fill this area from page cache on pte > >> > level later. > >> > > >> > This means we don't need deposit page tables when file THP is mapped. > >> > Therefore we shouldn't try to withdraw a page table on zap_huge_pmd() > >> > file THP PMD. > >> > >> Archs like ppc64 use deposited page table to track the hardware page > >> table slot information. We probably may want to add hooks which arch can > >> use to achieve the same even with file THP > > > > Could you describe more on what kind of information you're talking about? > > > > Hardware page table in ppc64 requires us to map each subpage of the huge > page. This is needed because at low level we use segment base page size > to find the hash slot and on TLB miss, we use the faulting address and > base page size (which is 64k even with THP) to find whether we have > the page mapped in hash page table. Since we use base page size of 64K, > we need to make sure that subpages are mapped (on demand) in hash page > table. If we have then mapped we also need to track their hash table > slot information so that we can clear it on invalidate of hugepage. > > With THP we used the deposited page table to store the hash slot > information. Could you prepare the patch with these hooks so we can discuss it details? I still have hard time wrap my had around this. I think you have the same problem with DAX huge pages. Or you don't care about DAX? -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
