linux-kernel - Re: [GIT pull] Timer core updates for 4.16

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:   Wed, 31 Jan 2018 07:27:40 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Anna-Maria Gleixner <anna-maria@...utronix.de>
Subject: Re: [GIT pull] Timer core updates for 4.16


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Mon, Jan 29, 2018 at 10:30 PM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > These are in cases significant driver simplifications, but they also enable the
> > real deal, the elimination of the hrtimer tasklet:
> >
> >  softirq: Remove tasklet_hrtimer
> >
> >    include/linux/interrupt.h | 25 -----------------------
> >    kernel/softirq.c          | 51 -----------------------------------------------
> >    2 files changed, 76 deletions(-)
> >
> > ... which is a pretty nice thing in itself even without the driver
> > simplifications!
> >
> > Plus the _real_ secret motivation behind it all is the -rt kernel and
> > CONFIG_PREEMPT_RT=y and the ability to push most of the hrtimer processing into
> > softirq context - while it still keeps the main hrtimer machinery capable to run
> > in hard-RT hardirq domain. Turns out it was possible to implement this duality via
> > the softirq-hrtimers, with a good chunk of benefits to non-rt upstream as well.
> 
> So this is the kind of explanation that I would have liked in the
> "please pull" (and that would have been great in the merge message).
> Explaining not just the "what", but very much the "why".
> 
> Anyway, it's obviously pulled regardless, and I'm just pointing this
> out for "maybe next time".

Yeah, and there will be a next time: we'll apply those those networking code 
simplifications and the tasklet removal for the v4.17 merge window, and include 
the full description in that pull request.

That cannot retroactively make it easier for you to apply the first batch of 
patches, but at least we'll have the meta description in the next merge commit and 
it will be part of the v4.17 Git history.

Thanks,

	Ingo