From owner-freebsd-arch@FreeBSD.ORG Fri Jun 29 01:18:07 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB37816A400 for ; Fri, 29 Jun 2007 01:18:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 803DE13C447 for ; Fri, 29 Jun 2007 01:18:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id AFFD54773F; Thu, 28 Jun 2007 21:00:04 -0400 (EDT) Date: Fri, 29 Jun 2007 02:00:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeff Roberson In-Reply-To: <20070628123314.W552@10.0.0.1> Message-ID: <20070629015656.I50751@fledge.watson.org> References: <20070628123314.W552@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Add wakeup_with() before 7.0? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2007 01:18:07 -0000 On Thu, 28 Jun 2007, Jeff Roberson wrote: > I propose to add a new api for wakeup before 7.0. This new api would accept > a wait channel and a flags argument. here's the relevant part of the diff: > > +void wakeup_with(void *chan, int flags) __nonnull(1); > +#define WAKEUP_ONE 0x00001 /* Only wakeup on thread. */ > +#define WAKEUP_ALL 0x00002 /* Wake-up all waiters. */ > +#define WAKEUP_LOCAL 0x00004 /* Wake-up on the local cpu. What will this flag do if there are no sleepers on the current CPU, but there are sleepers on other CPUs? > */ > +#define WAKEUP_TAIL 0x00008 /* Wake-up the newest waiter. > */ Another flag I've played with adding in the past has been WAKEUP_NOPREEMPT, which would hint to the scheduler that a brief priority inversion is preferred to excessive context switching. > To implement this change sched_wakeup() and setrunnable() need the flags > plummed all the way through. I would like feedback on whether people think > the api breakage should go in now to enable these optimizations for 7.0, > potentially without committing users of these flags right away. > Alternatively we could break the api later or just skip it until 8.0. I've not looked at the details here, but my general feeling is that if we think that making the API change now is low-risk (i.e., won't be error-prone), and we think it's very unlikely we might want to further revise them, I'm OK with it happening before the branch. I think I wouldn't expose the flags themselves at this point in 7.x, just the function prototype change. Robert N M Watson Computer Laboratory University of Cambridge