Messages in this thread | | | Date | Wed, 28 Sep 2022 14:06:45 +0200 | From | Sebastian Andrzej Siewior <> | Subject | Re: [PATCH v3] random: use expired per-cpu timer rather than wq for mixing fast pool |
| |
On 2022-09-27 12:42:33 [+0200], Jason A. Donenfeld wrote: … > This is an ordinary pattern done all over the kernel. However, Sherry > noticed a 10% performance regression in qperf TCP over a 40gbps > InfiniBand card. Quoting her message: > > > MT27500 Family [ConnectX-3] cards: > > Infiniband device 'mlx4_0' port 1 status: …
While looking at the mlx4 driver, it looks like they don't use any NAPI handling in their interrupt handler which _might_ be the case that they handle more than 1k interrupts a second. I'm still curious to get that ACKed from Sherry's side.
Jason, from random's point of view: deferring until 1k interrupts + 1sec delay is not desired due to low entropy, right?
> Rather than incur the scheduling latency from queue_work_on, we can > instead switch to running on the next timer tick, on the same core. This > also batches things a bit more -- once per jiffy -- which is okay now > that mix_interrupt_randomness() can credit multiple bits at once.
Hmmm. Do you see higher contention on input_pool.lock? Just asking because if more than once CPUs invokes this timer callback aligned, then they block on the same lock.
Sebastian
| |