Date: Fri, 25 Jun 1999 00:08:05 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: smp@freebsd.org Subject: Re: Call to arms..-SMP (fwd) Message-ID: <Pine.BSF.3.95.990625000729.2943A-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
---------- Forwarded message ----------
Date: Thu, 24 Jun 1999 17:16:22 -0400 (EDT)
From: Luoqi Chen <luoqi@watermarkgroup.com>
To: alc@cs.rice.edu, bde@freebsd.org, dyson@iquest.net, julian@whistle.com,
luoqi@freebsd.org
Subject: Re: Call to arms..-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.
> Ideas? Code? I'm asking because I think most of you know the low-level
> assembly glue that would have to be modified better than I do right
> now.
>
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.
> Alan
>
-lq
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?Pine.BSF.3.95.990625000729.2943A-100000>