Re: Heads up

[Andrew Doran <ad%netbsd.org@localhost>]

On Thu, Apr 24, 2008 at 09:04:51PM +0200, Juan RP wrote:

> On Thu, 24 Apr 2008 19:56:42 +0100
> Andrew Doran <ad%netbsd.org@localhost> wrote:
> 
> > Hi,
> > 
> > I changed a lot of the socket code and process locking stuff in the kernel
> > today. While I have tested many areas, as always it's possible that there
> > are bugs lurking.
> > 
> > On a positive note, I'm finished making gut-wrenching changes for SMP and
> > it's likely to be bugfixes and new features in isolation from me going
> > forward, so hopefully I won't have to send any more of these e-mails. :-)
> > Sorry about all the breakage over the last 2 years. I believe that the end
> > product of those changes will be worth it.
> 
> Great work.

Cheers.
 
> Could you please make a summary of the code that still runs with the
> kernel_lock?

o Some file systems, for example lfs, ext2fs, nfs. To be honest about it
  that's the last problem we should care about when it comes to lfs, but nfs
  is almost there. Already the nfs server (nfsd) is MPSAFE thanks to
  Yamamoto-san's efforts. The file systems that don't need kernel_lock are,
  if I remember correctly: ffs, procfs, cd9660, tmpfs, mfs, nullfs. Maybe
  also overlayfs, I don't remember right now.

o Most of the device drivers still take kernel lock. It's not a big deal for
  most workloads, but with a large disk array and lots of I/O going on it
  would not be as efficient as it could be, especially with software RAID5.

o Wire-protocols like TCP/IP. The network interface drivers also take the
  kernel_lock. This is currently being worked on (not by me).

o Veriexec needs it.

o A few isolated bits of the kernel like the powerpc pmap module. Mostly
  in MD/compat code and very limited in number.

Andrew