Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD/vax current
On 20 April 2014 10:23, Anders Magnusson <ragge%ludd.ltu.se@localhost> wrote:
> 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]
>>>
>>> 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.
If it worked it could even be ifdefed to allow HZ to be set to
divisors of 100...
> 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.
Presumably on vax its calling out to statclock() and schedclock() as well as
callout_hardclock() each tick. I know a lot of counters have moved
from 32bit to 64bit since early NetBSD which might also have affected
things...
It looks like there is definitely enough possibilities for someone
with the time and right machines to investigate.
I'd be very happy to contribute beer money ($100) towards someone
looking into this, and/or help pay to get a machine to someone who is
interested but doesn't have the right kit. Would anyone else be
interested in putting into a pot (or drinking the pot :)
David
Home |
Main Index |
Thread Index |
Old Index