Re: extra PG_* bits for page->flags

From: Andrew Morton (
Date: Mon Feb 10 2003 - 19:20:18 EST

Nigel Cunningham <> wrote:
> On Tue, 2003-02-11 at 12:12, Andrew Morton wrote:
> > David Howells <> 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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:31 EST