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

Reply via email to