[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6be2e0e-52a8-f711-ac37-23f267864710@bristot.me>
Date: Mon, 6 May 2019 09:17:04 +0200
From: Daniel Bristot de Oliveira <daniel@...stot.me>
To: Marcelo Tosatti <mtosatti@...hat.com>,
linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org
Cc: Thomas Gleixner <tglx@...utronix.de>,
Anna-Maria Gleixner <anna-maria@...utronix.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Luiz Capitulino <lcapitulino@...hat.com>,
Haris Okanovic <haris.okanovic@...com>
Subject: Re: [patch 0/3] do not raise timer softirq unconditionally
(spinlockless version)
On 5/6/19 5:22 AM, Marcelo Tosatti wrote:
> On Mon, Apr 15, 2019 at 05:12:13PM -0300, Marcelo Tosatti wrote:
>> For isolated CPUs, we'd like to skip awakening ktimersoftd
>> (the switch to and then back from ktimersoftd takes 10us in
>> virtualized environments, in addition to other OS overhead,
>> which exceeds telco requirements for packet forwarding for
>> 5G) from the sched tick.
>>
>> The patch "timers: do not raise softirq unconditionally" from Thomas
>> attempts to address that by checking, in the sched tick, whether its
>> necessary to raise the timer softirq. Unfortunately, it attempts to grab
>> the tvec base spinlock which generates the issue described in the patch
>> "Revert "timers: do not raise softirq unconditionally"".
>>
>> tvec_base->lock protects addition of timers to the wheel versus
>> timer interrupt execution.
>>
>> This patch does not grab the tvec base spinlock from irq context,
>> but rather performs a lockless access to base->pending_map.
>>
>> It handles the the race between timer addition and timer interrupt
>> execution by unconditionally (in case of isolated CPUs) raising the
>> timer softirq after making sure the updated bitmap is visible
>> on remote CPUs.
>>
>> This patchset reduces cyclictest latency from 25us to 14us
>> on my testbox.
>>
>>
>
> Ping?
>
Hi Marcelo,
I've been running your patches with lockdep and other debug options and did not
find any problem of this kind. Also, I did not find any kind of timing
regressions in tests with the PREEMPT RT...
-- Daniel
Powered by blists - more mailing lists