Re: extra PG_* bits for page->flags

[Nigel Cunningham <ncunningham@clear.net.nz>]

On Tue, 2003-02-11 at 13:20, Andrew Morton wrote:
> 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.

So bits <= 27 should be safe or are guaranteed safe? :> (Keep in mind
that people are starting to port swsusp to other archs)

> PG_checked is supposed to be removed - I have not looked into that.  PG_slab
> is fairly optional.
AFAICS, PG_checked is cleared in page_alloc.c and only otherwise used in
fs/ext2/dir.c, freexfs/xvfs_subr.c(commented out actually) and
afs/dir.c.

For PG_slab, should I understand 'fairly optional' to mean 'possibly
dangerous' (ie don't use)?

> 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.

I can still happily do a few dynamically allocated bitmaps if there are
better things the bits can be used for. (The flags are not costly redo
and need to be redone each suspend & resume anyway).

Of course, on top of all of these questions, Pavel might not like my
code anyway so this might be a moot point :>

Anyway, for the moment, I'll proceed on the assumption that there'll be
enough flags, and I can always switch if needs be.

Regards,

Nigel