On Mon, 2005-03-14 at 13:50 -0800, David S. Miller wrote:
> On Mon, 14 Mar 2005 13:14:43 -0800
> Dave Hansen <[EMAIL PROTECTED]> wrote:
>
> > Three of these are i386-only, but one of them reorganizes the macros
> > used to manage the space in page->flags, and will affect all platforms.
> > There are analogous patches to the i386 ones for ppc64, ia64, and
> > x86_64, but those will be submitted by the normal arch maintainers.
>
> Sparc64 uses some of the upper page->flags bits to store D-cache
> flushing state.
>
> Specifically, PG_arch_1 is used to set whether the page is scheduled
> for delayed D-cache flushing, and bits 24 and up say which CPU the
> CPU stores occurred on (and thus which CPU will get the cross-CPU
> message to flush it's D-cache should the deferred flush actually
> occur).
>
> I imagine that since we don't support the domain stuff (yet) on sparc64,
> your patches won't break things, but it is something to be aware of.
Those bits are used today for page_zone() and page_to_nid(). I assume
that you don't support NUMA, but how do you get around the page_zone()
definition? (a quick grep in asm-sparc64 didn't show anything obvious)
static inline struct zone *page_zone(struct page *page)
{
return zone_table[page->flags >> NODEZONE_SHIFT];
}
BTW, in theory, the new patch should allow page->flags to be better
managed by a variety of users, including special arch users. An
architecture should be able to relatively easily add the necessary
pieces to reserve them. We could even have a ARCH_RESERVED_BITS macro
or something.
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
