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

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

On 8/15/24 23:44, Olivier Langlois wrote:
> On Thu, 2024-08-15 at 18:17 -0400, Olivier Langlois wrote:
>>
>> To my eyes, what is really important, it is that absolute best
>> technical solution is choosen and the only way that this discussion
>> can
>> be done, it is with numbers. So I have created a small created a
>> small
>> benchmark program to compare a function pointer indirect call vs
>> selecting a function in a 3 branches if/else if/else block. Here are
>> the results:

FWIW, it's just one branch / two different options in this case.
We shouldn't be doing a call if napi has never been requested,
so napi_dont_do_anything callback is not an option.

>> ----------------------------------------------------------
>> Benchmark                Time             CPU   Iterations
>> ----------------------------------------------------------
>> BM_test_virtual      0.628 ns        0.627 ns    930255515
>> BM_test_ifElse        1.59 ns         1.58 ns    446805050
>>
> I have fixed my benchmark:
> 
> ----------------------------------------------------------
> Benchmark                Time             CPU   Iterations
> ----------------------------------------------------------
> BM_test_virtual       2.57 ns         2.53 ns    277764970
> BM_test_ifElse        1.58 ns         1.57 ns    445197861

You passed the compiler flags for mitigations, right?

-mindirect-branch=thunk  -mfunction-return=thunk -mindirect-branch-register

Regardless of overhead, my concern is the complexity and
amount of extra code. It's just over engineered. It's like
adding a virtual templated hierarchy of classes just to
implement a program that prints "2".

I pushed what I had (2 last patches), you can use it as a
reference, but be aware that it's a completely untested
draft with some obvious problems and ugly uapi.

https://github.com/isilence/linux.git manual-napi
https://github.com/isilence/linux/commits/manual-napi/

-- 
Pavel Begunkov