svn commit: r357004 - in head/sys: kern sys

[Cy Schubert]

In message <7d7db96d-26b1-1d2b-9f8d-a3f8fbe8c33c at selasky.org>, Hans Petter 
Sela
sky writes:
> On 2020-01-24 18:05, Gleb Smirnoff wrote:
> > On Fri, Jan 24, 2020 at 10:24:53AM +0100, Hans Petter Selasky wrote:
> > H> What you want to do here is right, but how it is implemented is wrong,
> > H> in my opinion.
> > H>
> > H> 1) Remove intr_epoch_batch. Most network drivers use interrupt
> > H> moderation, and a timeout of 1000 iterations can easily become 1 second
> > H> under heavly load !
> > 
> > If a driver has interrupt moderation than epoch batching counter
> > basically won't ever grow over 1. It kicks in only of driver doesn't
> > have it, or receives interrupts at a very high rate.
>
> Depending on the load an interrupt imposes, this batching counter may 
> cause epochs to last for a long time. Have you considered using ticks 
> for this instead? I.E. if the congestion lasts more than two ticks, then 
> re-acquire the EPOCH?
>
> For example if the network controller spends more time processing 
> packets then there is between interrupts, then this unconditional 1000x 
> thing can be quite dangerous.
>
> > 
> > H> 2) You need to make a new request function for interrupts which take a
> > H> pointer to an EPOCH and replace that IH_NET in hflags!
> > 
> > Initially I did that way, but then pondered over this approach and have
> > abandoned it.  Most likely we will have just few globally recognized
> > epochs in the kernel. And even less might be associated with interrupt
> > handlers. Complexity and performance impact of using a pointer are
> > noted by Drew in D23347.
>
> Let not the network epoch become the new Giant of EPOCH's. There might 
> be realtime constraints for EPOCH's aswell.

I also had that concern yesterday.

Obtaining an EPOCH higher up the call stack or lower down depends on the 
workload. Are there any measurements that moving the EPOCHs higher in the 
call stack improves one workload (and configuration) or another? Could one 
type of workload or configuration benefit from this at the expense of 
another workload or configuration?

>
> Secondly, I don't see how 8000 IRQs per second will cause any problem 
> accessing a pointer in the interrupt handler structure? A well designed 
> ethernet driver use coalescing of packets and the the IRQ rate goes 
> down. What Drew is referring to are badly designed ethernet cards with 
> very small DMA rings, so the speak.
>
> If the IRQ handler is executed hundreds of thousand times per second, 
> that is a problem in itself and reading one more pointer will have 
> little impact on the system.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.