| 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
| ||
|
Date: Fri, 26 Nov 2010 18:07:36 +0100 From: Tejun Heo <tj@...nel.org> To: Eric Dumazet <eric.dumazet@...il.com> CC: Christoph Lameter <cl@...ux.com>, akpm@...ux-foundation.org, Pekka Enberg <penberg@...helsinki.fi>, linux-kernel@...r.kernel.org, Mathieu Desnoyers <mathieu.desnoyers@...icios.com> Subject: Re: [thiscpuops upgrade 08/10] percpu: generic this_cpu_cmpxchg() and this_cpu_cmpxchg_double support On 11/26/2010 06:01 PM, Eric Dumazet wrote: >> What I'm afraid of is generic code switching to use it in very hot >> paths when a lot of archs can't actually do it leading to performance >> regressions. Is this something which is available on most archs? >> > > I would say cmpxchg() has the same problem, some arches dont have a > native instruction, yet we use it in some paths. Yeah, well, there's difference between some not having it and only x86_64 having it. cmpxchg was already rather well received when it was added even though it wasn't available on all archs. I'm not against it but think we should use some caution here and think about the impact of unoptimized cases which can be pretty common (preemption toggling isn't too expensive but irq toggling can be quite). Thanks. -- tejun -- 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/
Powered by blists - more mailing lists