Re: extra PG_* bits for page->flags

[Andrew Morton <akpm@digeo.com>]

Nigel Cunningham <ncunningham@clear.net.nz> wrote:
>
> On Tue, 2003-02-11 at 12:12, Andrew Morton wrote:
> > David Howells <dhowells@redhat.com> wrote:
> > >  (*) PG_journal
> > >  (*) PG_journalmark
> > 
> > Well.  If you new fs goes in then yes, we can spare those bits (just).
> 
> May I ask, how many bits do you consider available?

Too darn few, frankly.

> swsusp beta 18 (ie
> 2.4), which I'm beginning to port to 2.5, uses 4 bits during suspend &
> resume for various purposes. If I understand the code correctly, the
> zone flags use bits 24-31 (although there has been that thread saying
> they could use less bits). I see in the 2.5.60 patch bit 19 is now in
> use. Should I be using private, temporarily allocated bitmaps instead of
> the page flags, to ease the pressure? (Especially since the suspend code
> is not used in 'normal' operation anyway).

256 zones is fairly exorbitant.  I suspect the number of machines which have

a) more than 16 zones and 
b) CONFIG_SOFTWARE_SUSPEND

is zero. So you can always munch into the top eight bits.

PG_checked is supposed to be removed - I have not looked into that.  PG_slab
is fairly optional.

PG_highmem can go away.  (just use page_zone(page)->is_highmem)

I would dearly like to dump PG_reserved, but I doubt if I'll get onto that.
(thinks about what happens if you start a direct-io read from a soundcard DMA
buffer, and munmap/close while that is in progress...)

So.  There's not a lot of fat there, but we're not all out of options.