Re: Performance problems.

[Johnny Billquist <bqt%softjar.se@localhost>]

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).

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.

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

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.

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

        Johnny