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.1205072227540.6271@ionos>
Date:	Mon, 7 May 2012 22:33:20 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Chris Metcalf <cmetcalf@...era.com>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [patch 17/18] tile: Use common threadinfo allocator

On Mon, 7 May 2012, Chris Metcalf wrote:
> On 5/7/2012 3:45 PM, Thomas Gleixner wrote:
> > What's the difference between a kernel stack page for a given node and
> > a page which is allocated on a given node ?
> 
> No difference except in how it is allocated (and of course how it is
> used).  The task migration code currently knows that the kernel stack
> should have its home cache migrated; it finds it by VA.  In the absence of
> migration the kernel stack page is not treated differently than any other
> page_alloc'ed page.
> 
> >> 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? 
> 
> The advantage is that when you initially allocate the stack page, you can
> set its home cache appropriately to be on the local cpu, where the new task
> is likely to run.  Otherwise, you could imagine using a suitable hook for
> when the task starts up to migrate the page at that point, but you miss out
> on the opportunity to have the allocator return a suitably-cached page up
> front when the task is created.
> 
> > 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?
> 
> There are certainly different possible ways to tell the allocator to
> allocate a page with its cache "here" vs with its cache fully-distributed
> (and thus less local, and less good for stack or percpu pages).  We use a
> different approach (some per-task data structures that pass homing info to
> the allocator) but we could probably use GFP_ values instead.  But the
> point is we need to be able to know to do so, and I think the only obvious
> way is to override something in the threadinfo allocator.

Wrong. The obvious way is to use the common code and add a special
flag to it.

There is nothing wrong to add

#ifndef ARCH_THREADINFO_GFP
#define ARCH_THREADINFO_GFP (0)
#endif

and or ARCH_THREADINFO_GFP to the generic THREADINFO_GFP flags

instead of insisting on a separate allocator function for something
which has no fricking reason to be arch specific (IA64 and some weird
sparc crap aside)

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/