Michael L. Hitch wrote:
On Wed, 12 May 2010, Johnny Billquist wrote:So something seems to be able to lock out the clock from interrupting for rather long times. Clock interrupts happens at IPL_SCHED, so this would seem to mean that the system is running at IPL_HIGH for extended periods (I don't think anything is using the IPL levels in between).Anyone have any ideas what this might be?There are several things that could be affecting this. One is the reduction of IPL levels in the kernel (I can never remember exactly what they are, but I think they include IPL_HIGH, IPL_SCHED, IPL_VM, and IPL_NONE). Mapping of hardware interupt levels to these may affect things. Another thing is that I feel there is much more locking going on in the kernel with spin mutexes and there may more time spent at higher IPLs than there used to be previously. Associated with this is the way mutexes work. Nested spin mutexes do not lower the IPL until the final mutex exits. This means that if a spin mutex at IPL_HIGH is done while a lower IPL spin mutex is held, the exit of the IPL_HIGH mutex will continue running at IPL_HIGH until all the nested spin mutexes have exited. I can't point to any specific case where this actually happens though.
Yeah, I was trying to see if there are any other potential levels that now map to the same level, but I haven't seen any so far.
There might be a lot more locking going on, though. But seriously, are there any need for spin locks on a uniprocessor system? We should be able to just expand those to nothing?
One other point. You say clock interrupts happen at IPL_SCHED and that the system might be running at IPL_HIGH for extended periods. If the system is running at IPL_SCHED, I think that also will block any clock interrupts at IPL_SCHED.
Right. But as I said somewhere, I don't have any clock interrupt misses appear when I look at the point of the exit from the hard clock interrupt. So that don't seem to be it. But yes, if someone else raises to IPL_SCHED, that would lock clock interrupts out just as good.
But the real kicker is that I'm not all that sure the clock interrupts at IPL_SCHED. According to my VAX Architecture Reference Manual, the interval clock interrupts at IPL 24 (0x18, which is IPL_SCHED) on the 11/780, 11/750, and 11/730 systems. The preferred interrupt is IPL 22 (0x16) - which happens to be lower than IPL_VM (0x17), so the clock interrupt will be blocked during any code protected by a spin mutex.
Well, this is a 8650, so I would definitely suspect that clocks really happens at IPL 24. I could check, though.
But you raise a good point here. If the newer VAXen have lowered the clock interrupt, it will change the behaviour of things. But as far as I can tell, this would only make the whole thing possibly worse on newer machines, not better.
The fact that they might be faster might help, though.
Need to think and experiment some more here...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol