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 email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/