Messages in this thread | | | Date | Mon, 10 Feb 2003 16:20:18 -0800 | From | Andrew Morton <> | Subject | Re: extra PG_* bits for page->flags |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |