linux-kernel - Re: [RFC] [PATCH] x86: avoid per

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, 19 Jul 2013 10:24:22 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andrew Hunter <ahh@...gle.com>
Cc:	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	x86@...nel.org, Yinghai Lu <yinghai@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RFC] [PATCH] x86: avoid per_cpu for APIC id tables


* Ingo Molnar <mingo@...nel.org> wrote:

> [...]
> 
> Also, if the goal is to pack better then we could do even better than 
> that: we could create a 'struct x86_apic_ids':
> 
>   struct x86_apic_ids {
> 	u16 bios_apicid;
> 	u16 apicid;
> 	u32 logical_apicid;	/* NOTE: does this really have to be 32-bit? */
>   };
> 
> and put that into an explicit, [NR_CPUS] array. This preserves the tight 
> coupling between fields that PER_CPU offered, requiring only a single 
> cacheline fetch in the cache-cold case, while also giving efficient, 
> packed caching for cache-hot remote wakeups.
> 
> [ Assuming remote wakeups access all of these fields in the hot path to 
>   generate an IPI. Do they? ]
> 
> Also, this NR_CPUS array should be cache-aligned and read-mostly, to avoid 
> false sharing artifacts. Your current patch does not do either.

Btw., if you implement the changes I suggested and the patch still 
provides a robust 10% improvement in the cross-wakeup benchmark over the 
vanilla kernel then that will be a pretty good indication that it's the 
cache-hot layout and decreased indirection cost that makes the difference 
- and then we'd of course want to merge your patch upstream.

Also, a comment should be added to the new [NR_CPUS] array explaining that 
it's a special data structure that is almost always accessed from remote 
CPUs, and that for that reason PER_CPU accesses are sub-optimal: to 
prevent someone else from naively PER_CPU-ifying the [NR_CPUS] array later 
on ;-)

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/