Re: page_waitqueue() considered harmful

[Nicholas Piggin <npiggin@gmail.com>]

On Thu, 29 Sep 2016 10:01:30 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Tue, Sep 27, 2016 at 09:54:12AM +0100, Mel Gorman wrote:
> > On Tue, Sep 27, 2016 at 09:30:55AM +0200, Peter Zijlstra wrote:
> > Simple is relative unless I drastically overcomplicated things and it
> > wouldn't be the first time. 64-bit only side-steps the page flag issue
> > as long as we can live with that.  
> 
> So one problem with the 64bit only pageflags is that they do eat space
> from page-flags-layout, we do try and fit a bunch of other crap in
> there, and at some point that all will not fit anymore and we'll revert
> to worse.
> 
> I've no idea how far away from that we are for distro kernels. I suppose
> they have fairly large NR_NODES and NR_CPUS.

I know it's not fashionable to care about them anymore, but it's sad if
32-bit architectures miss out fundamental optimisations like this because
we're out of page flags. It would also be sad to increase the size of
struct page because we're too lazy to reduce flags. There's some that
might be able to be removed.

PG_reserved - We should have killed this years ago. More users have crept
back in.

PG_mappedtodisk - Rarely used, to slightly shortcut some mapping lookups.
Possible for filesystems to derive this some other way, e.g.,
PG_private == 1 && ->private == NULL, or another filesystem private bit.
We should really kill this before more users spring up and it gets stuck
forever. 

PG_swapcache - can this be replaced with ane of the private bits, I wonder?

PG_uncached - this is PG_arch_2 really, but unfortunately x86 uses both.
Still, that and PG_arch_1 could be removed from most architectures, so
many of the 32-bit ones could use the extra flags.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>