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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1205072134130.6271@ionos>
Date:	Mon, 7 May 2012 21:45:57 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Chris Metcalf <cmetcalf@...era.com>
cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch 17/18] tile: Use common threadinfo allocator

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@...utronix.de>
> > Cc: Chris Metcalf <cmetcalf@...era.com>
> > ---
> >  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/