Re: [PATCH 0/4] sparsemem intro patches

[Dave Hansen <haveblue@us.ibm.com>]

On Mon, 2005-03-14 at 13:50 -0800, David S. Miller wrote:
> On Mon, 14 Mar 2005 13:14:43 -0800
> Dave Hansen <haveblue@us.ibm.com> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>