On Wed, 10 Jul 2002, Bruce Evans wrote:
> 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).
That (use ast) is a sensible suggestion. I guess it belongs
with the postsig in ast().
I can try that.. though it ;ll take a little work
in the mean time try the patch above with lmbench..
>
> Bruce
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
