Re: [PATCH 0/2] abstract napi tracking strategy

[Pavel Begunkov <asml.silence@gmail.com>]

On 8/13/24 23:36, Pavel Begunkov wrote:
> On 8/13/24 22:25, Olivier Langlois wrote:
>> On Tue, 2024-08-13 at 12:33 -0600, Jens Axboe wrote:
>>> On 8/13/24 10:44 AM, Olivier Langlois wrote:
>>>> the actual napi tracking strategy is inducing a non-negligeable
>>>> overhead.
>>>> Everytime a multishot poll is triggered or any poll armed, if the
>>>> napi is
>>>> enabled on the ring a lookup is performed to either add a new napi
>>>> id into
>>>> the napi_list or its timeout value is updated.
>>>>
>>>> For many scenarios, this is overkill as the napi id list will be
>>>> pretty
>>>> much static most of the time. To address this common scenario, a
>>>> new
>>>> abstraction has been created following the common Linux kernel
>>>> idiom of
>>>> creating an abstract interface with a struct filled with function
>>>> pointers.
>>>>
>>>> Creating an alternate napi tracking strategy is therefore made in 2
>>>> phases.
>>>>
>>>> 1. Introduce the io_napi_tracking_ops interface
>>>> 2. Implement a static napi tracking by defining a new
>>>> io_napi_tracking_ops
>>>
>>> I don't think we should create ops for this, unless there's a strict
>>> need to do so. Indirect function calls aren't cheap, and the CPU side
>>> mitigations for security issues made them worse.
>>>
>>> You're not wrong that ops is not an uncommon idiom in the kernel, but
>>> it's a lot less prevalent as a solution than it used to. Exactly
>>> because
>>> of the above reasons.
>>>
>> ok. Do you have a reference explaining this?
>> and what type of construct would you use instead?
>>
>> AFAIK, a big performance killer is the branch mispredictions coming
>> from big switch/case or if/else if/else blocks and it was precisely the
>> reason why you removed the big switch/case io_uring was having with
>> function pointers in io_issue_def...
> 
> Compilers can optimise switch-case very well, look up what jump
> tables is, often works even better than indirect functions even
> without mitigations. And it wasn't converted because of performance,
> it was a nice efficient jump table before.

Correction, switches were optimisable until -fno-jump-tables was
added because of speculations, makes it equal with indirect calls,
and otherwise there were usually retpolined making it equal to
indirect calls.

-- 
Pavel Begunkov