Re: [patch 17/18] tile: Use common threadinfo allocator

[Thomas Gleixner]

On Sat, 5 May 2012, Chris Metcalf wrote:

> On 5/5/2012 11:05 AM, Thomas Gleixner wrote:
> > Use the core allocator and deal with the extra cleanup in
> > arch_release_thread_info().
> >
> > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > Cc: Chris Metcalf <cmetcalf@xxxxxxxxxx>
> > ---
> >  arch/tile/include/asm/thread_info.h |    6 ++----
> >  arch/tile/kernel/process.c          |   23 ++---------------------
> >  2 files changed, 4 insertions(+), 25 deletions(-)
> 
> We have some changes we haven't yet merged upstream that this will likely
> conflict with.
> 
> You may note that we have APIs like homecache_alloc_pages() that take a
> core or other magic value to indicate what the "home" cache should be on
> our architecture.  This enables significant performance optimizations when
> you can co-locate the home cache with where most of the core references are
> coming from.
> 
> The additional changes we haven't yet merged are in the area of managing
> the home cache dynamically.  Rather than just setting the home cache at
> allocation time, we allow it to be modified dynamically: for example, as
> the process migrates, we migrate the kernel and user stack pages.  This is
> tricky since there are lots of coherence issues to manage, and the changes
> we have include a variety of changes in the core mm code to handle
> transitioning the home cache, proper locking, unmapping, hooks in the buddy
> allocator, blocking other cores while a page is transitioning, etc etc.
> 
> But, the relevance to this change is that as part of that code, we use the
> homecache_alloc_page() method to set the home cache of a kernel stack page
> to be the core that is running the thread (and then migrate the home cache
> dynamically after that).  Using the new proposed core allocator will mean
> we lose that hook.  We don't need a free hook (when we're using the dynamic
> mode we are already hooked into the allocator itself), but we do need a way
> to know when we're allocating a kernel stack page as opposed to any other
> kind of a page.

What's the difference between a kernel stack page for a given node and
a page which is allocated on a given node ?
 
> The simplest approach is of course just to allow
> __HAVE_ARCH_THREAD_INFO_ALLOCATOR to continue to be meaningful and use it
> for tile, but maybe there's some halfway point.  For example, that symbol
> could refer only to the allocate function, and not also imply an
> arch-specific free function.  Or, we could have a new much more focused
> override that was just "a function to use instead of alloc_pages_node",
> e.g. provide a weak alloc_threadinfo_pages_node() that just was generically
> just a call to alloc_pages_node, which architectures could override.

Again, that would give you what? 

If you treat kernel stack pages different to general pages allocated
on a node then why not using a special GFP flag for that purpose?

Thanks,

	tglx
--
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/