atom feed7 messages in org.freebsd.freebsd-smpRe: Call to arms..-SMP (fwd)
FromSent OnAttachments
Julian ElischerJun 25, 1999 12:07 am 
Julian ElischerJun 25, 1999 12:08 am 
Julian ElischerJun 25, 1999 12:08 am 
Julian ElischerJun 25, 1999 12:08 am 
Mike SmithJun 25, 1999 12:13 am 
Terry LambertJun 25, 1999 9:51 am 
Julian ElischerJun 25, 1999 11:01 am 
Subject:Re: Call to arms..-SMP (fwd)
From:Mike Smith (mi@smith.net.au)
Date:Jun 25, 1999 12:13:51 am
List:org.freebsd.freebsd-smp

I'd like to make a modest proposal to get things started: Can we modify the various kernel entry points so that they don't acquire the giant lock(s) by default and instead parameterize the decision. In other words, somewhere associate a bit/flag with each trap/syscall, etc. that determines whether or not the lock is acquired. This would make incremental multithreading of the kernel easy, which I think is important. There's a fair bit of low-hanging fruit that this would enable us to pick. For example, there are a number of syscalls in the VM system that I could almost immediately enable multithreading of.

I say let's do this.

I'm not entirely sure that dissociating the lock status of a syscall from the implementation of the syscall is a good idea.

If we assume that the new implementation of the lock involves counting (so that one syscall may chain to another with the lock DTRT), then I would feel even more strongly about inlining the lock acquisition. This would also make moving it around a lot easier.

Not much assembly is need. All we need to do is to make SYSCALL_LOCK a nop, and handle the locking in syscall() the C function.

Don't even do it here; put the lock acquisitions/releases in the syscall implementation functions themselves.

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message