linux-kernel - Re: [PATCH v4 00/36] hrtimer: Provide softirq context hrtimers

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180116013917.qkm3codqbugskgwk@gmail.com>
Date:   Tue, 16 Jan 2018 02:39:17 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Anna-Maria Gleixner <anna-maria@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, keescook@...omium.org,
        Christoph Hellwig <hch@....de>,
        John Stultz <john.stultz@...aro.org>
Subject: Re: [PATCH v4 00/36] hrtimer: Provide softirq context hrtimers


* Anna-Maria Gleixner <anna-maria@...utronix.de> wrote:

> There are quite some places in the kernel which use a combination of
> hrtimers and tasklets to make use of the precise expiry of hrtimers, which
> schedule a tasklet to bring the actual function into softirq context.
> 
> This was introduced when the previous hrtimer softirq code was
> removed. That code was implemented by expiring the timer in hard irq
> context and then deferring the execution of the callback into softirq
> context. That caused a lot of pointless shuffling between the rbtree and a
> linked list.
> 
> In recent discussions it turned out that more potential users of hrtimers
> in softirq context might come up. Aside of that the RT patches need this
> functionality as well to defer hrtimers into softirq context if their
> callbacks are not interrupt safe on RT.
> 
> This series implements a new approach by adding SOFT hrtimer mode and
> instead of doing the list shuffle, timers started with this mode are put
> into separate soft expiry hrtimer queues. These queues are evaluated only
> when the hardirq context detects that the first expiring timer in the
> softirq queues has expired. That makes the overhead in the hardirq context
> minimal.
> 
> The series reworks the code to reuse as much as possible from the existing
> facilities for the new softirq hrtimers and integrates them with all
> flavours of hrtimers (HIGH_RES=y/n - NOHZ=y/n).
> 
> To achieve this quite some of the conditionals in the existing code are
> removed for the price of adding some pointless data and state tracking to
> the HIGH_RES=n case. That's minimal, but well worth it as it increases the
> readability and maintainability of the code.
> 
> The first part of the series implements the new functionality and the
> second part converts the hrtimer/tasklet users to make use of it and
> removes struct hrtimer_tasklet and the surrounding helper functions.
> 
> This series is available from git as well:
> 
> 	git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.timers
> 
> Thanks,
> 
>         Anna-Maria

Nice work!

A general heads-up: I've applied most of this series to tip:timers/core, and while 
reviewing the changes I've tidied up a number of changelogs and titles and 
modified a few in-code comments as well - but have not changed any logic code.

No serious changes intended, but please double check the end result once I've 
pushed it out after local testing.

Thanks,

	Ingo