Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Aug 2002 12:33:03 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Alfred Perlstein <bright@mu.org>
Cc:        Andrew Gallatin <gallatin@cs.duke.edu>, Bruce Evans <bde@zeta.org.au>, Ian Dowse <iedowse@maths.tcd.ie>, arch@FreeBSD.ORG
Subject:   Re: Solving the stack gap issue
Message-ID:  <200208201933.g7KJX37j084635@apollo.backplane.com>
References:  <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> <15714.17605.575558.398279@grasshopper.cs.duke.edu> <20020820153515.GL75574@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help


:* Andrew Gallatin <gallatin@cs.duke.edu> [020820 06:32] wrote:
:> 
:> For example, why do we check MPSAFE and conditionally grab and release
:> GIANT in syscall instead of just grabbing/releasing it in the syscall
:> itself?  A few thousand instructions worth of bloat might be worth 2
:> compares in the critical path..  Also, if the copyin fails, why do we
:> not just set the ret value and jump past the call, rather than setting
:> error and doing an extra compare a few lines later?
:
:Grunt work that just needs to be done.  I can take a shot at it
:if no one else is currently. 
:
:-- 
:-Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net]
:

    Please feel free to proceed, Alfred.  I think we are at the point
    where we can get rid of the MPSAFE flag and shift Giant operation
    from the syscall trap code to the individual syscall procedures.

    It is, as you say, just a lot of grunt work.

    I originally put the MPSAFE code in the syscall trap handler because 
    it was the most convenient solution, and performance wasn't an issue
    back then.  I doubt people will notice the performance difference with
    Giant shifted to the syscalls but from an engineering perspective I
    think it's a good cleanup to make because it makes it easier for people
    working on the syscalls to shift Giant inward.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

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




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