lkml.org 
[lkml]   [2003]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.075 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site