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 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?




[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