[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Performance problems.
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
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...
Main Index |
Thread Index |