From owner-p4-projects Wed Apr 10 12:11:43 2002 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 6CDFB37B404; Wed, 10 Apr 2002 12:11:38 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from fw.wemm.org (12-232-135-171.client.attbi.com [12.232.135.171]) by hub.freebsd.org (Postfix) with ESMTP id 5900937B400; Wed, 10 Apr 2002 12:11:37 -0700 (PDT) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (8.11.6/8.11.6) with ESMTP id g3AJCuQ25104; Wed, 10 Apr 2002 12:12:56 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 92F753810; Wed, 10 Apr 2002 12:12:20 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Doug Rabson Cc: Jake Burkholder , John Baldwin , Perforce Change Reviews Subject: Re: PERFORCE change 9504 for review In-Reply-To: Date: Wed, 10 Apr 2002 12:12:20 -0700 From: Peter Wemm Message-Id: <20020410191220.92F753810@overcee.wemm.org> Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Doug Rabson wrote: > On Wed, 10 Apr 2002, Jake Burkholder wrote: > > > Apparently, On Wed, Apr 10, 2002 at 09:06:18AM -0400, > > John Baldwin said words to the effect of; > > > > > > > > On 10-Apr-2002 Peter Wemm wrote: > > > > http://people.freebsd.org/~peter/p4db/chv.cgi?CH=9504 > > > > > > > > Change 9504 by peter@peter_thunder on 2002/04/10 04:51:36 > > > > > > > > Use dfr's fix instead of my hack. I expect he'll commit this to > > > > freefall soon. :-) > > > > > > Yep, much better. :) > > > > Well, now the flag checking code is duplicated in both the trap and syscall > > return paths, alpha is the same. One wonders if the FRAME_SYSCALL optimiza tion > > is actually worth all this complication. > > I think its still worth it - it still does a lot less work in the common > case. Bear in mind that calling ast() is quite rare and being forced to do > a full exception restore (e.g. for a signal) is even rarer. A harmless > extra call to ast() in that case is unlikely to be noticable. Having said > that, for ia64 at least, it should be possible for the syscall to bypass > the ast() bits at the beginning of exception_restore(). As long as syscall > sets (p1,p2) to (1,0), it can jump to label 2 in exception_restore. John asked an awkward question a while ago.. What happens if the ast() call in the back of the fast syscall return path changes the frame type? eg: it posted a signal and turned off the FRAME_SYSCALL bit. We'll continue with the fast return, right? Is this good or bad? Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message