From owner-freebsd-current Tue Jul 9 16: 3:33 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6FD337B400; Tue, 9 Jul 2002 16:03:30 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89C2943E4A; Tue, 9 Jul 2002 16:03:29 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id JAA16600; Wed, 10 Jul 2002 09:03:22 +1000 Date: Wed, 10 Jul 2002 09:06:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: John Baldwin , FreeBSD current users , FreeBSD current users Subject: RE: userret() , ast() and the end of syscalls In-Reply-To: Message-ID: <20020710090100.Q8947-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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