Messages in this thread | | | Date | Tue, 11 Feb 2003 15:17:03 +1300 | From | Nigel Cunningham <> | Subject | Re: extra PG_* bits for page->flags |
| |
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
- 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/
| |