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.
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ msm...@freebsd.org
\\ -- Joseph Merrick \\ msm...@cdrom.com
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message