linux-kernel - Re: [PATCHSET] x86: unify x86_32 and 64 NUMA init paths, take#4

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]

Date:	Thu, 30 Dec 2010 12:14:05 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Tejun Heo <tj@...nel.org>
CC:	linux-kernel@...r.kernel.org, mingo@...hat.com, tglx@...utronix.de,
	x86@...nel.org, eric.dumazet@...il.com, yinghai@...nel.org,
	brgerst@...il.com, gorcunov@...il.com, penberg@...nel.org,
	shaohui.zheng@...el.com, rientjes@...gle.com
Subject: Re: [PATCHSET] x86: unify x86_32 and 64 NUMA init paths, take#4

On 12/30/2010 09:49 AM, Tejun Heo wrote:
> 
> The only change from the last take[L] is that it's now based on
> tip/x86/numa.  Unfortunately, some of the collisions weren't trivial
> and led to some ugliness.
> 
> Commit c1c3443c ("x86, numa: Fake node-to-cpumask for NUMA emulation")
> introduced hard dependency on x86_64 into numa_add/remove_cpu() when
> CONFIG_NUMA_EMU is enabled.  0015 has been updated so that the 32/64
> bit common versions used when !CONFIG_NUMA_EMU are in numa.c while
> CONFIG_NUMA_EMU variants are in numa_64.c.
> 
> This is ugly but still better than before.  IIUC, Shaohui's patchsets
> is going to unify NUMA emulation across 32 and 64bit, which should
> remove the above ugliness.  I haven't looked through the patchset yet
> but after skimming through the current NUMA_EMU code, here are some of
> my thoughts, FWIW.
> 
> * There's no reason for different NUMA config methods to construct
>   different data structures.  They all, including 32bit, can build a
>   single set of data structures.
> 
> * Then, unification of NUMA_EMU would naturally follow.  There's no
>   reason to think about whether the underlying NUMA and proximity
>   information is provided by ACPI, AMD or whatever.  It just needs to
>   manipulate the processed data.
> 
> Let's _please_ head that way instead of adding more gluing codes and
> hacks everywhere.  It would be a bit more churn but I don't think
> there's any other sustainable way.
> 

Agreed 100%.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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