Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Jul 2002 09:06:33 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Julian Elischer <julian@elischer.org>
Cc:        John Baldwin <jhb@FreeBSD.ORG>, FreeBSD current users <current@FreeBSD.ORG>, FreeBSD current users <current@FreeBSD.ORG>
Subject:   RE: userret() , ast() and the end of syscalls
Message-ID:  <20020710090100.Q8947-100000@gamplex.bde.org>
In-Reply-To: <Pine.BSF.4.21.0207091453230.35930-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Jul 2002, Julian Elischer wrote:

> On Wed, 10 Jul 2002, Bruce Evans wrote:
>
> > Hopefully there won't be any unconditional code.  Unconditional code
> > in userret() pessimizes all syscalls.  Unconditional code added by KSEIII
> > pessimized basic syscall overhead by 10% according to lmbench2.
>
> Mostly it's conditional..
> 	if (p->p_flag & P_KSES)
> in syscall()
> and
> 	if (p->p_flag & P_KSES) {
> in userret()

The conditionals are unconditional, and together with the proc locking)
(mainly the locking) are what gives the 10% pessimization.  It would be
much more than 10% to actually do something :).

> it's probably
>         PROC_LOCK(p);
>         thread_suspend_check(0);        /* Can suspend or kill */
>         PROC_UNLOCK(p);
>
>
> try replace it with:
>         if (P_SHOULDSTOP(p) {
>                 PROC_LOCK(p);
>                 thread_suspend_check(0);        /* Can suspend or kill */
>                 PROC_UNLOCK(p);
>         }

Can these flags be changed asynchronously?  If so, then everything needs
to be handled by ast() anyway.  userret() should only check for work that
needs doing in the usual case, and hopefully there is none (except for
things like ktrace).

Bruce


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?20020710090100.Q8947-100000>