Re: Interesting data on network interrupt - part II

From: Julian Elischer <julian_at_elischer.org>
Date: Thu, 06 Apr 2006 11:18:45 -0700
John Baldwin wrote:

>On Wednesday 05 April 2006 17:40, Julian Elischer wrote:
>  
>
>>John Baldwin wrote:
>>
>>    
>>
>>>On Tuesday 04 April 2006 20:33, Paolo Pisati wrote:
>>> 
>>>
>>>      
>>>
>>>>Hi, 
>>>>
>>>>i updated my work on interrupt profiling with sone new
>>>>experiments.
>>>>
>>>>In total we have now:
>>>>
>>>>-FreeBSD 4 PIC (no asm part)
>>>>-FreeBSD 7 APIC 
>>>>-FreeBSD 7 PIC
>>>>-FreeBSD 7 PREE APIC
>>>>-FreeBSD 7 APIC JHB
>>>>
>>>>Some quick comments:
>>>>
>>>>-PIC is much slower in masking interrupt (7k in PIC vs 3k in APIC)
>>>>-PREE let new thread save less than 500 ticks of 'queue' while 
>>>>preempted threads are often resumed after a lot
>>>>-JHB patch shaved 2.5k ticks in interrupt masking op
>>>>
>>>>For graphs, data and more comments:
>>>>
>>>>http://mercurio.sm.dsi.unimi.it/~pisati/interrupt/
>>>>   
>>>>
>>>>        
>>>>
>>>I'll commit the patch then. :)  One thing you might try to do to better
>>>measure the effects of preemption is to generate kernel work so that
>>>the bge interrupts occur while the current thread is in the kernel
>>>rather than in userland.  In that case preemption should provide much
>>>lower latency for interrupt handlers, as w/o preemption, an interrupt
>>>in kernel mode won't run the ithread until either curthread blocks or
>>>returns to userland.
>>> 
>>>
>>>      
>>>
>>it looks a bit like the preempted threads shuld be put onto a stack of 
>>threads to resume
>>so that when the pre-empter finishes, teh previosly active thread is 
>>resumed.
>>Basically, a preempted thread should be put at the HEAD of it's run 
>>queue, and not the tail..
>>    
>>
>
>You changed the scheduler to already do that.
>  
>

oh, yeah,..... at least I'm consistent..
Received on Thu Apr 06 2006 - 17:10:55 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:54 UTC