Re: [RFC net-next 0/5] Suspend IRQs during preferred busy poll

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-08-19 22:36, Jakub Kicinski wrote:
On Sun, 18 Aug 2024 10:51:04 -0400 Martin Karsten wrote:
I believe this would take away flexibility without gaining much. You'd
still want some sort of admin-controlled 'enable' flag, so you'd still
need some kind of parameter.

When using our scheme, the factor between gro_flush_timeout and
irq_suspend_timeout should *roughly* correspond to the maximum batch
size that an application would process in one go (orders of magnitude,
see above). This determines both the target application's worst-case
latency as well as the worst-case latency of concurrent applications, if
any, as mentioned previously.

Oh is concurrent applications the argument against a very high
timeout?

Only in the error case. If suspend_irq_timeout is large enough as you
point out above, then as long as the target application behaves well,
its batching settings are the determining factor.

Since the discussion is still sort of going on let me ask something
potentially stupid (I haven't read the paper, yet). Are the cores
assumed to be fully isolated (ergo the application can only yield
to the idle thread)? Do we not have to worry about the scheduler
deciding to schedule the process out involuntarily?

That shouldn't be a problem. If the next thread(s) can make progress, nothing is lost. If the next thread(s) cannot make progress, for example waiting for network I/O, they will block and the target application thread will run again. If another thread is busy-looping on network I/O, I would argue that having multiple busy-looping threads competing for the same core is probably not a good idea anyway.

Thanks,
Martin





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux