• Thomas Gleixner's avatar
    posix-cpu-timers: Provide mechanisms to defer timer handling to task_work · 1fb497dd
    Thomas Gleixner authored
    Running posix CPU timers in hard interrupt context has a few downsides:
    
     - For PREEMPT_RT it cannot work as the expiry code needs to take
       sighand lock, which is a 'sleeping spinlock' in RT. The original RT
       approach of offloading the posix CPU timer handling into a high
       priority thread was clumsy and provided no real benefit in general.
    
     - For fine grained accounting it's just wrong to run this in context of
       the timer interrupt because that way a process specific CPU time is
       accounted to the timer interrupt.
    
     - Long running timer interrupts caused by a large amount of expiring
       timers which can be created and armed by unpriviledged user space.
    
    There is no hard requirement to expire them in interrupt context.
    
    If the signal is targeted at the task itself then it won't be delivered
    before the task returns to user space anyway. If the signal is targeted at
    a supervisor process then it might be slightly delayed, but posix CPU
    timers are inaccurate anyway due to the fact that they are tied to the
    tick.
    
    Provide infrastructure to schedule task work which allows splitting the
    posix CPU timer code into a quick check in interrupt context and a thread
    context expiry and signal delivery function. This has to be enabled by
    architectures as it requires that the architecture specific KVM
    implementation handles pending task work before exiting to guest mode.
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
    Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20200730102337.783470146@linutronix.de
    1fb497dd
Kconfig 4.96 KB