Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Mar 2000 13:04:47 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: Why are all accesses to the cpl surrounded by a lock?
Message-ID:  <20000325130447.I21029@fw.wintelcom.net>
In-Reply-To: <200003250527.VAA19096@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Mar 24, 2000 at 09:27:57PM -0800
References:  <200003250527.VAA19096@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [000324 21:52] wrote:
>     I've been doing more SMP cleanup and for the life of me I can't figure
>     out why cpl operations are surrounded by its own [S]CPL_LOCK ??
> 
>     As far as I can tell, the cpl is only accessed/modified:
> 
> 	* by mainline code while the MP lock is held 
> 	* by an interrupt while the MP lock is held
> 
>     Since any modification of the cpl within an interrupt is paired and
>     thus from the point of view of mainline code the cpl does not change
>     at all (i.e. s = splvm(); ... splx(s);), I don't see why the cpl needs 
>     to be locked at all.  We shouldn't even need to use a 'lock' prefix.
> 
>     Now, I understand that we eventually want to get out from under the MP
>     lock's thumb, but it needs to be pointed out that the cpl mechanism
>     itself is likely to be depreciated in favor of something more 
>     thread-friendly.  I don't see any point in trying to make the cpl
>     operate independantly of the MP lock at this time.
> 
>     Does anyone know why all the locking was added to the cpl code?

It doesn't make much sense to me either.  I spoke to Terry about
the history of the SMP work and he said that it was originally much
more thread safe and used spl as part of the subsystem locking, if
that's true then it makes sense to lock spl to realize that.

Otherwise right now your guess is as good as mine.

As a side note, it seems silly that we do this:

        MPLOCKED incl _cnt+V_SYSCALL
        SYSCALL_LOCK
        call    _syscall

I think per-cpu statistics would be an interesting optimization,
since you're testing all of this, have you been able to measure
the getuid() loop with and without this (MPLOCKED incl _cnt+V_SYSCALL),
especially with 2 processes doing a getuid() loop?

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000325130447.I21029>