| From | Sent On | Attachments |
|---|---|---|
| Julian Elischer | Jun 25, 1999 12:07 am | |
| Julian Elischer | Jun 25, 1999 12:08 am | |
| Julian Elischer | Jun 25, 1999 12:08 am | |
| Julian Elischer | Jun 25, 1999 12:08 am | |
| Mike Smith | Jun 25, 1999 12:13 am | |
| Terry Lambert | Jun 25, 1999 9:51 am | |
| Julian Elischer | Jun 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.
-- \\ 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





