On 2010-11-19 13:36, Thor Lancelot Simon wrote:
On Fri, Nov 19, 2010 at 01:04:50PM +0100, Johnny Billquist wrote:Doh! Stupid of me. I just realized how mutexes can be taken without ever passing through mutex_enter or mutex_vector_enter, even if they are defined. We also have mutex_tryenter, which cannot be redefined.So make it so it can be redefined.
Done. Now I just need to fix hppa so that it will be happy again (as far as I can tell, that's the only archtecture that defines it's own mutex operations, apart from VAX).
I've also trimmed the mutex code down quite a lot for the VAX, and it seems to work fine now. I'm doing some serious testing of it to see if it holds up.
Next should be rwlocks, but I'm much less eager to try that one, but I guess I should anyway. And I should try to document a little more of what I have figured out on the subject of mutexes, since we don't really have any proper (or even correct) documentation on how your own mutex code needs to look like, in order to work.
The sad part though, is that it helped less than I had hoped for from a performance point of view. I'm guessing that we've actually also included a lot more overhead in the kernel in general, that causes the slowdown. And I don't know how to locate it, or trim it away. System time (when running top) shows that the system is spending very much time in system. Running a cvs update and building a pkgsrc at the same time, and system time is often over 50%, sometimes hitting close to 90%, which is bad. What I don't get is why it take so much time to even respond to pings, compared to Ultrix or VMS. What are we doing in the kernel??? As usual, I'm open to suggestions...
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