Date: Fri, 25 Jun 1999 00:14:13 -0700 From: Mike Smith <mike@smith.net.au> To: Julian Elischer <julian@whistle.com> Cc: smp@freebsd.org Subject: Re: Call to arms..-SMP (fwd) Message-ID: <199906250714.AAA00587@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 25 Jun 1999 00:08:05 PDT." <Pine.BSF.3.95.990625000729.2943A-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906250714.AAA00587>