linux-kernel - Re: [PATCH 15/16] x86: Unify node_to_cpumask

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] [day] [month] [year] [list]

Date:	Fri, 31 Dec 2010 15:09:16 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Tejun Heo <tj@...nel.org>
cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	tglx@...utronix.de, "H. Peter Anvin" <hpa@...or.com>,
	x86@...nel.org, eric.dumazet@...il.com, yinghai@...nel.org,
	brgerst@...il.com, gorcunov@...il.com,
	Pekka Enberg <penberg@...nel.org>, shaohui.zheng@...el.com
Subject: Re: [PATCH 15/16] x86: Unify node_to_cpumask_map handling between
 32 and 64bit

On Fri, 31 Dec 2010, Tejun Heo wrote:

> > (and the unification that can be done in the meantime would only be the 
> > actual apicid-to-node and pxm-to-node mappings after it is exported from 
> > amd and acpi specific functions), so I'd prefer to handle cleanups as 
> > incremental patches on top of those.
> 
> The problem is that those "incremental" patches often don't happen
> once the itch is gone while the immediate fixes/improvements aggravate
> existing complications.  If you were/are planning to clean it up, I
> have nothing to whine about.  :-)
> 

We can certainly implement i386 NUMA emulation after the unification is 
done (only to avoid additional conflicts on your set :), but I'm not sure 
if there's an audience of testers and debuggers who want to use it for 
i386 NUMA; there hasn't been one in the past when people like Magnus Damm 
proposed it about four years ago.  Agreed that it's probably going to be 
simpler after your unification patchset is merged, but it seems like we're 
in the unique position where we're extending a feature for an architecture 
because it's simple and makes things cleaner in the code rather than being 
actually useful.
--
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/