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: Tue, 20 Aug 2013 17:29:12 +0200 From: Frederic Weisbecker <fweisbec@...il.com> To: Peter Zijlstra <peterz@...radead.org>, Arjan van de Ven <arjan@...ux.intel.com>, "Rafael J. Wysocki" <rjw@...k.pl>, Viresh Kumar <viresh.kumar@...aro.org> Cc: Fernando Luis Vázquez Cao <fernando_b1@....ntt.co.jp>, Oleg Nesterov <oleg@...hat.com>, Ingo Molnar <mingo@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [PATCH 2/4] nohz: Synchronize sleep time stats with seqlock On Tue, Aug 20, 2013 at 10:44:05AM +0200, Peter Zijlstra wrote: > On Tue, Aug 20, 2013 at 03:59:36PM +0900, Fernando Luis Vázquez Cao wrote: > > That said, if deemed acceptable, option A is the one I would > > choose. > > Right, so I think we can do A without much extra cost mostly because we > already have 2 atomics in the io_schedule() path. If we replace those > two atomic operations with locks and modify nr_iowait and the other > stats under the same lock, and ensure all those variables (including the > lock) live in the same cacheline we should have the same cost we have > now. I can try that :-) > > Of course, if we can get away with completely removing all of that > (which I think Arjan suggested was a real possibility) then that would > be ever so much better still :-) Would be lovely. But I don't know much about cpufreq, I hope somebody who's familiar with that code can handle this. Then once there are no more users of get_cpu_iowait_sleep_time() I can simply zap and clean the tick/time related code. Surely the overhead that this mess brings to io_schedule() (and it's going to be worth with a seqlock, whether in the same cacheline than nr_iowait or not) may be a good motivation to poke at that cpufreq code part. Thanks. -- 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