Re: Performance problems.

[Matt Thomas <matt%3am-software.com@localhost>]

On May 5, 2010, at 9:09 AM, Johnny Billquist wrote:

> Tobias Nygren wrote:
>> On Wed, 05 May 2010 12:11:59 +0200
>> Johnny Billquist <bqt%softjar.se@localhost> wrote:
>>> Anyone else seen this, knows what could be affecting it, or care?
>>> Or are all others just using modern fast machines, where all this don't 
>>> really make a blip on the radar anyway, or else is not using their machines 
>>> enough to make this visible?
>> My gut feeling is that even on comparatively fast sparc64 hardware more
>> cycles are spent these days doing kernel work. But it may simply be
>> that the accounting in top(1) is broken / calculated differently from
>> how it used to be done. Benchmark results of current vs. 2.0 on low
>> powered uniprocessor systems would be very interesting to see.
> 
> I'm trying to look at this now, but what I'm looking at right now don't seem 
> to have any bearing on sparcs, sorry.
> 
> That said, maybe someone can help me with a few details here. I'm looking at 
> the softint code. Currently, there exists a __HAVE_FAST_SOFTINT option for 
> the kernel. The only two architectures that seem to have defined this is x86 
> and VAX.
> So far, so good.
> 
> But looking further into kern/kern_softint.c, I see a number of calls to 
> softint_init_isr, where the second parameter is said to be the interrupt 
> priority. The comments and descriptions about soft interrupt priorities say:
> 
> *     The four priority levels map directly to scheduler priority
> *     levels, and where the architecture implements 'fast' software
> *     interrupts, they also map onto interrupt priorities.  The
> *     interrupt priorities are intended to be hidden from machine
> *     independent code, which should use thread-safe mechanisms to
> *     synchronize with software interrupts (for example: mutexes).

IPL_SOFTCLOCK is what that is referring to and those are defined correctly.


> If I understand all of this right, the priorities should then match the 
> actual interrupt priorities if you have fast software interrupts.
> And for the softclock, this is PRI_SOFTCLOCK. But looking at the definition 
> of PRI_SOFTCLOCK, it is defined as
> 
> sys/sys/param.h:#define PRI_SOFTCLOCK   (MAXPRI_KERNEL_RT - schedppq * 3)
> 
> which I *very much* doubt becomes a suitable interrupt priority on a VAX.

PRI_xxx is not an interrupt priority, but a scheduling priority.

> Am I reading and understanding things wrong here, or is this fundamentally 
> wrong in design? If the priority levels should match the interrupt levels in 
> the case of fast soft interrupts, I can't understand why the definitions are 
> in the MI files. It should be pretty machine dependent...

The former.

> Since only the VAX and x86 are using fast soft interrupts, I can see that the 
> code might have been written so that it works on the x86. Since noone else 
> uses it, noone else gets hit by this but the VAX.

Actually, MIPS is using them now too.

> If anyone can shed some more light on this, please do. In the meanwhile, I'll 
> just do some blind testing and see if changing this will help...