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: Wed, 17 Dec 2014 13:47:30 +0100 From: Frederic Weisbecker <fweisbec@...il.com> To: Thomas Gleixner <tglx@...utronix.de> Cc: Preeti U Murthy <preeti@...ux.vnet.ibm.com>, Viresh Kumar <viresh.kumar@...aro.org>, Fengguang Wu <fengguang.wu@...el.com>, Frederic Weisbecker <frederic@...nel.org>, "Pan, Jacob jun" <jacob.jun.pan@...el.com>, LKML <linux-kernel@...r.kernel.org>, LKP <lkp@...org>, Peter Zijlstra <peterz@...radead.org> Subject: Re: [nohz] 2a16fc93d2c: kernel lockup on idle injection On Wed, Dec 17, 2014 at 10:11:58AM +0100, Thomas Gleixner wrote: > On Wed, 17 Dec 2014, Frederic Weisbecker wrote: > > On Tue, Dec 16, 2014 at 10:21:27PM +0100, Thomas Gleixner wrote: > > > So instead of evaluating the whole nonsense a gazillion times in a row > > > and firing pointless self ipis why are you not looking at the obvious > > > solution of sane state change tracking? > > > > Because I had to do it wrong first before somebody like you with a fresh mind > > comes, look at the whole picture and propose a rethink :-) > > Point taken. > > > > I told all of you from the very beginning that remote accounting > > > is a key mechanism for this, but you keep insisting on hacking > > > around it. > > > > I don't, and I think everybody has understood we are not going to accept > > hacks to solve the 1hz issue. > > You wish. > > > I'm pretty sure you know what this is about to maintain a project with a > > (variably) cruel lack of manpower ;-) > > Oh yes! :( > > > Moreover I'm not the kind of kernel developer who ignores reviews (whether pre or > > post merge). > > I know that. > > > So, no point in threatening a dependency to BROKEN or ripping out except perhaps to > > push me out to other projects with more thankful managers. > > This was not directed to you, really. > > This was directed at the folks who randomly "fix" that code by voodoo > bandaids instead of analyzing the root causes in the first > place. You're the least one to blame for that. Well I was about to propose a bad fix for powerclamp and I sometimes take overengineering directions. I'm still to blame for several things 8-) Sorry I got too touchy :-) Anyway, I'll give a try to your proposition. Somehow I have always felt that something was wrong with this tick_nohz_can_stop_tick() called all over the place, that plus the IPI that's often near the scheduler IPI. I'm pretty sure this is going to help fixing some overhead issues I got reported. Thanks a lot! -- 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