cvs commit: src/sys/i386/i386 pmap.c

[Julian Elischer]

Scott Long wrote:

> Stephan Uphoff wrote:
>
>> On Tue, 2004-11-09 at 13:02, Julian Elischer wrote:
>>
>>> Robert Watson wrote:
>>>
>>>
>>>> This change made a large difference, and eliminates the unexplained 
>>>> costs.
>>>> Here's a revised table as compared to the above:
>>>>
>>>>     sleep mutex    crit section    spin mutex    new spin mutex
>>>>     UP    SMP    UP    SMP    UP    SMP    UP    SMP
>>>> PIII    21    81    83    81    112    141    95    141
>>>> P4    39    260    120    119    274    342    132    231
>>>>
>>>> So it basically cut 140 cycles off the P4 UP spin lock, 15 off the 
>>>> PIII UP
>>>> spin lock, and 110 cycles off the P4 SMP spin lock.  The PIII SMP spin
>>>> lock looks the same.  Keep in mind that all of these measurements 
>>>> have a
>>>> standard deviation of between 0 and 3 cycles, most in the 1 range.  
>>>> Also
>>>> keep in mind that these are entirely uncontended measurements.
>>>>
>>>> Assuming that these changes are correct, and pass whatever tests 
>>>> people
>>>> have in mind, this would be a very strong merge candidate for 
>>>> performance
>>>> reasons.  The difference is visible in packet send tests from user 
>>>> space
>>>> as a percentage or two improvement on UP on my P4, although it's a 
>>>> litte
>>>> hard to tell due to the noise.
>>>>
>>>
>>> Can you explain why a spin mutex is more expensive than a sleep 
>>> mutex (I assume this is uncontested)?
>>
>>
>>
>> cli() and sti() used for the critical section are expensive.
>> ( The spin mutex includes the critical section)
>>
>> I recall a USENIX paper about avoiding the cost of cli(),sti() by just
>> setting an in memory flag. The interrupt handler was modified to honor
>> the flag and delay interrupt processing until the flag was cleared.
>> This may have the potential to drastically decrease the cost of a spin
>> mutex if interrupts during critical regions are infrequent.
>>
>>     Stephan
>>
>
> You mean create a word, let's just call it an 'intrmask_t', that can be
> set and cleared by the OS and drivers, and checked in the interrupt
> handler to see if the interrupt should be serviced right away or not?
> Hmmm... we'd have to think up a name for the API..... hmmmm... maybe
> spl()?
>
> =-) 


yes..
maybe we need to re-imp[lelemnt it.
in a sort-of "all-or-nothing" way

splhi() and splx() and nothing between.

>
>
> Scott