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@xxxxxxxxxxxxx> > > > 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
