Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD/vax current



David Brownlee skrev 2014-04-20 10:46:
On 20 April 2014 04:20, Anders Magnusson <ragge%ludd.ltu.se@localhost> wrote:
[about NetBSD slowniness on vax]

For someone who is curious; some time ago (about 15 years) I noticed that
NetBSD had become very slow on 11/750; unreasonable slow compared to other
machines.

I started searching and found that quite much time were spent in hardclock.
This is an effective way to make a slow machine much more sluggish.

Here is a simple explanation for someone not a low-level hacker:

Hardclock runs each 10ms.  We can say that it takes 500 instructions to
complete.  On a 1 MIPS machine we will spend 10000 instructions between each
hardclock interrupt, of which 9500 will be for user programs (~95%).  On a
1GIPS machine we have 10000000 instructions, of which 9999500 will be used
for processes (~99.9%).

Suddenly something is added that makes hardclock take 5000 instructions
instead.  On the 1MIPS machine we now only have 50% of the CPU left, but on
the newer machine we still have 99.9% of the CPU left (== not noticeable).
Something like this can only be seen on a really slow machine, it's most
likely not possible to find it even with fine-grain profiling on a modern
PC.

Back then, it turned out to be some NTP and timekeeping using long long
calculations that did eat up hardclock.   Just commenting out this made the
machine just as slow as before :-)
Would building a kernel with a lower HZ be a quick way to test?
That would require other changes also. Only the big VAXen has an adjustable clock interval (which is hardcoded to 10ms), microvax has a fixed 10ms clock interval. But adding some assembler in intvec.S:hardclock that only takes each fifth interrupt would be doable just to test, yes.

Another thing to be noted is that calls on vax might be quite slow, a vague memory tells me that average it takes about 10us for one calls (depending on how many regs to be saved). So if hardclock code path contains many calls it will affect the execution speed unreasonably much.

-- Ragge


Home | Main Index | Thread Index | Old Index