On Mon, 2015-09-21 at 17:23 +0530, Aneesh Kumar K.V wrote: > The page that contain pte entries. Or the last level of the linux page > table. or we could call them pte fragments. We need to allocate one > full page at lowest level, because we want to use split ptlock. Now > for keeping the pte_t entries, we will just be using 2K space. Rest of > the space can be reused. We did that in commit > 5c1f6ee9a31cbdac90bbb8ae1ba4475031ac74b4 . Now all those pmd entries > that have pte page (pte fragments) coming from the same 64K page > will also end up sharing the same ptlock.
Ok, I'm still a bit confused between what we do today vs. what we do after your patch, can you provide a clear description (maybe with ASCII art) of what is used, how, an how much is wasted overall when not using subpages ? > > > > In any case, shouldn't we consider something more like what we do for > > subpage protection and just segregate the 4k stuff in a completely > > separate tree which we can allocate on-demand so that we don't allocate > > any of it if there is no demotion ? > > > > We could definitely try that. That would mean another set of memory > allocation only for 4K and I was not sure we want that. For > example current subpage protection code path is rarely used and we may > not really be able to find out if we break it. That's what test suites are for, we should write a test case :) Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev