* Matthew Dillon <[EMAIL PROTECTED]> [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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
