On Mon, May 08 2023 at 12:08, Jason Xing wrote:
> On Fri, May 5, 2023 at 7:25 PM Liu Jian <liujian56@xxxxxxxxxx> wrote:
>> @@ -489,7 +490,7 @@ asmlinkage __visible void do_softirq(void)
>> * we want to handle softirqs as soon as possible, but they
>> * should not be able to lock up the box.
>> */
>> -#define MAX_SOFTIRQ_TIME msecs_to_jiffies(2)
>> +#define MAX_SOFTIRQ_TIME (2 * NSEC_PER_MSEC)
>
> I wonder if it affects those servers that set HZ to some different
> values rather than 1000 as default.
The result of msecs_to_jiffies(2) for different HZ values:
HZ=100 1
HZ=250 1
HZ=1000 2
So depending on when the softirq processing starts, this gives the
following ranges in which the timeout ends:
HZ=100 0 - 10ms
HZ=250 0 - 4ms
HZ=1000 1 - 2ms
But as the various softirq handlers have their own notion of timeouts,
loop limits etc. and the timeout is only checked after _all_ pending
bits of each iteration have been processed, the outcome of this is all
lottery.
Due to that the sched_clock() change per se won't have too much impact,
but if the overall changes to consolidate the break conditions are in
place, I think it will have observable effects.
Making this consistent is definitely a good thing, but it won't solve
the underlying problem of soft interrupt processing at all.
We definitely need to spend more thoughts on pulling things out of soft
interrupt context so that these functionalities get under proper
resource control by the scheduler.
Thanks,
tglx
