From owner-freebsd-arch@FreeBSD.ORG Thu Jun 28 21:28:20 2007 Return-Path: X-Original-To: freebsd-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 538D716A46C for ; Thu, 28 Jun 2007 21:28:20 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id D141713C4BB for ; Thu, 28 Jun 2007 21:28:19 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o4so226483uge for ; Thu, 28 Jun 2007 14:28:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=q8Te2NL6FRSFc5hTG/jfxA13MIj1zeGBqILW5/stxdeEyQbA3ky+v3oc1ZoBYTN1zwXJ4ffvmUp/JuNVPrJkAyOjMU54cASnfu7WLJ0Ku2/1Z4Jnu+OBr8Bynvg9ck6lutu1qK13RoWk/E+/qzE+qGKJiAPnVXzlPjLC8NcKX+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=sRnDfIEywZkhO5yQO6OKF3PR5RRWkLhEYpnob+mqSNTewQscT28f/Wrh9XYjgBvQzbQ4JOPdZnz+luSfX4V7SqSFg/ZopZRDSwyN7QWCnOkhGuHCbFeZDfFVH31HauqGQWcEHj3w00JpwDp6fZUlz/uEZHD2XwO0HpDKu5xtxBc= Received: by 10.78.138.6 with SMTP id l6mr1201794hud.1183066098595; Thu, 28 Jun 2007 14:28:18 -0700 (PDT) Received: by 10.78.97.18 with HTTP; Thu, 28 Jun 2007 14:28:18 -0700 (PDT) Message-ID: <3bbf2fe10706281428t3543c396q5cb5bb61685a987f@mail.gmail.com> Date: Thu, 28 Jun 2007 23:28:18 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Jeff Roberson" In-Reply-To: <20070628135758.U552@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070628123314.W552@10.0.0.1> <200706281653.37930.jhb@freebsd.org> <20070628135758.U552@10.0.0.1> X-Google-Sender-Auth: 06111853b69c9678 Cc: freebsd-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: Thu, 28 Jun 2007 21:28:20 -0000 2007/6/28, Jeff Roberson : > On Thu, 28 Jun 2007, John Baldwin wrote: > > > On Thursday 28 June 2007 03:41:15 pm 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. */ > >> +#define WAKEUP_TAIL 0x00008 /* Wake-up the newest > >> waiter. */ > >> > >> This allows wakeup callers to hint the scheduler about various > >> information. WAKEUP_LOCAL would allow us to prefer affinity for the > >> waking cpu. I have patches to use this in pipe code and socket buffer > >> code that improve performance in some workloads. WAKEUP_TAIL could be > >> used for accept() which I have heard can significantly improve webserver > >> performance. > >> > >> 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. > > > > We have something like WAKEUP_TAIL (but different, it also prefers non-swapped > > out processes in addition to taking the most recently suspended thread) at > > work for accept() and it just modifies the sleepq code's choice in > > sleepq_signal() of which thread to pick, it doesn't touch any of the > > scheduler stuff at all. OTOH, I think the scheduler ABIs are ok to change > > during 7.x as they aren't exposed to any KLD's (no well-behaving ones anyway) > > as drivers, etc. should all be using higher-level APIs like cv_*() or > > *sleep(). > > In my implementation the WAKEUP_TAIL call just changes the sleepq as well. > It doesn't go down to the scheduler. I agree that well behaving drivers > should not use setrunnable() or sched_wakeup(). Maybe that is ok to > break later. Any other opinions? 1) I would like to call the function wakeup_flags() as wakeup_with() is not approprate IMHO 2) I would commit just for 8.0 since currently there is no real consumer of it. For 8.0 we can have time to rework the accept code in order to use it 3) Is the code of wakeup_with() alredy available? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein