linux-kernel - Re: [PATCH 4/4] x86, amd: Support L3 Cache Partitioning on AMD family 0x15 CPUs

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: <20110127124756.GA16094@elte.hu>
Date:	Thu, 27 Jan 2011 13:47:56 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Hans Rosenfeld <hans.rosenfeld@....com>
Cc:	"hpa@...or.com" <hpa@...or.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"Herrmann3, Andreas" <Andreas.Herrmann3@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH 4/4] x86, amd: Support L3 Cache Partitioning on AMD
 family 0x15 CPUs


* Hans Rosenfeld <hans.rosenfeld@....com> wrote:

> On Wed, Jan 26, 2011 at 03:56:08PM -0500, Ingo Molnar wrote:
> > * Hans Rosenfeld <hans.rosenfeld@....com> wrote:
> > > +#ifdef CONFIG_SMP
> > > +int amd_get_subcaches(int cpu)
> > 
> > Well, sprinkling it with CONFIG_SMP is pretty ugly. Also, there's no fundamental 
> > reason why this shouldnt work with UP. Yes, it makes most sense on SMP but such code 
> > should be SMP-invariant.
> 
> True, it is pretty ugly. And while the feature is pretty useless for UP,
> it would still work for compute_unit_id 0 in that case.
> 
> The problem is that cpuinfo_x86.compute_unit_id etc. don't exist unless
> CONFIG_SMP is enabled. I don't think there is any reason why this should
> be that way, but changing this just for this particular L3 feature seems
> too intrusive. Do you really want me to do that?

All the CONFIG_X86_HT #ifdefs in arch/x86/kernel/cpu/amd.c look pretty ugly too - 
and it's not really a properly modularized solution.

We generally want to unify the SMP and UP kernels as much as possible. 'CONFIG_SMP' 
is not really a property of the hardware, it's a property of the software.

If some topology information should be excluded then it can already be done by 
turning off CONFIG_CPU_SUP_AMD under CONFIG_EXPERT.

Thanks,

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