lkml.org 
[lkml]   [2023]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4] signal: Let tasks cache one sigqueue struct.
On 2023-04-07 04:53:27 [+0100], Matthew Wilcox wrote:
> On Fri, Apr 07, 2023 at 08:03:06AM +0800, Hillf Danton wrote:
> > On Thu, 6 Apr 2023 22:47:21 +0200 Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > > The sigqueue caching originated in the PREEMPT_RT tree. A few of the
> > > applications, that were ported to Linux, were ported from OS-9. Sending
> > > notifications from one task to another via a signal was a common
> > > communication model there and so the applications are heavy signal
> > > users. Removing the allocation reduces the critical path, avoids locks
> > > and so lowers the maximal latency of the task while sending a signal.
>
> It might lower the _average_ latency, but it certainly doesn't lower
> the _maximum_ latency, because you have to assume worst case scenario
> for maximum latency. Which is that there's no sigqueue cached, so you
> have to go into the slab allocator. And again, worst case scenario is
> that you have to go into the page allocator from there, and further that
> you have to run reclaim, and ...

Yes. The idea is in general not to send more signals in parallel than
the available number cached slots.

> What I find odd about the numbers that you quote:
>
> > The numbers of system boot followed by an allmod kernel build:
> > Out of 333216 allocations, 194876 (~58%) were served from the cache.
> > From all free invocations, 4212 were in a path were caching is not done
> > and 329002 sigqueue were cached.
>
> ... is that there's no absolute numbers. Does it save 1% of the cost
> of sending a signal? 10%? What does perf say about the cost saved
> by no longer going into slab? Because the fast path in slab is very
> fast. It might even be quicker than your fast path for multithreaded
> applications which have threads running on different NUMA nodes.

I asked for updated numbers and the improvement is not as big as
initially reported. There might have been a change in the configuration
for the testing an so the improvement is not as big as initially assumed.
I'm sorry, but I didn't get any numbers to back anything up. I'm
dropping the effort here, thanks for the review :)

Sebastian

\
 
 \ /
  Last update: 2023-05-24 17:33    [W:1.349 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site