Re: [RFC][PATCH] Dynamically allocated pageflags.

From: Dave Hansen
Date: Fri Feb 18 2005 - 22:07:35 EST


On Sat, 2005-02-19 at 13:43 +1100, Nigel Cunningham wrote:
> For some time now, we've been running out of bits for pageflags.
>
> In Suspend2, I need the functional equivalent of pageflags, but don't
> need them when Suspend isn't running. One of the outcomes of the last
> submission of Suspend2 for review was that I changed the format in which
> that data is stored, creating something I call dynamically allocated
> pageflags.
>
> It's a simple idea: we tie together a bunch of order zero allocated
> pages using a kmalloc'd list of poiinters to those pages, and store the
> location of that kmalloc'd list in what's really an unsigned long **
> (typedef'd). We also provide macros so that calls for setting and
> clearing flags can look just like ordinary pageflag set/clear/test
> invocations.
>
> Helpers are also provided for allocating and freeing the maps.

I'm kicking myself because I thought about this 2 minutes after we
talked on IRC.

One issue is that it doesn't work with DISCONTIGMEM (or the upcoming
sparsemem). max_mapnr doesn't exist on those systems, and on the really
discontiguous ones, you might be allocating very large areas with very
sparse maps.

One thing that I've been thinking about for these things is something
tree-based. A 1 or 2-level tree, like pagetables should be fast enough,
and handle the sparse and discontiguous layouts a little better than a
flat one. We could even do a flat bitmap for normal systems, and #ifdef
in the table only when it's needed. I can take a look at doing this
next week.

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/