Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752421Ab0D1Nmf (ORCPT ); Wed, 28 Apr 2010 09:42:35 -0400 Received: from mail-pv0-f174.google.com ([74.125.83.174]:39620 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751386Ab0D1Nmd convert rfc822-to-8bit (ORCPT ); Wed, 28 Apr 2010 09:42:33 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=nHfHeRaZjXsLCNFz0VyxA3GQ7Nkao1zcKLZ0lMi5GuODlTblHOl8JrqfFkku88uiAl +JEZpB2WZbyyd8h59hSb1BCw7eL+12ANGe93ncX/EHnGB4Y6LNn77GkZg4MEV9nEwvRS kmMrGEKzd3fpdArem7fGpQnDd37JmJFCBZigo= MIME-Version: 1.0 In-Reply-To: <20100428132135.GA22268@shareable.org> References: <1272430986-20436-1-git-send-email-xiaosuo@gmail.com> <20100428081545.GA19027@windriver.com> <8482.1272446987@redhat.com> <20100428132135.GA22268@shareable.org> From: Changli Gao Date: Wed, 28 Apr 2010 21:42:12 +0800 Message-ID: Subject: Re: [RFC] sched: implement the exclusive wait queue as a LIFO queue To: Jamie Lokier Cc: David Howells , Yong Zhang , Xiaotian Feng , Ingo Molnar , Alexander Viro , Andrew Morton , "Eric W. Biederman" , Davide Libenzi , Roland Dreier , Stefan Richter , Peter Zijlstra , "David S. Miller" , Eric Dumazet , Christoph Lameter , Andreas Herrmann , Thomas Gleixner , Takashi Iwai , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1876 Lines: 53 On Wed, Apr 28, 2010 at 9:21 PM, Jamie Lokier wrote: > Changli Gao wrote: >> >> fs/eventpoll.c: 1443. >>                 wait.flags |= WQ_FLAG_EXCLUSIVE; >>                 __add_wait_queue(&ep->wq, &wait); > > The same thing about assumptions applies here.  The userspace process > may be waiting for an epoll condition to get access to a resource, > rather than being a worker thread interchangeable with others. Oh, the lines above are the current ones. So the assumptions applies and works here. > > For example, userspace might be using a pipe as a signal-safe lock, or > signal-safe multi-token semaphore, and epoll to wait for that pipe. > > WQ_FLAG_EXCLUSIVE means there is no point waking all tasks, to avoid a > pointless thundering herd.  It doesn't mean unfairness is ok. The users should not make any assumption about the waking up sequence, neither LIFO nor FIFO. > > The LIFO idea _might_ make sense for interchangeable worker-thread > situations - including userspace.  It would make sense for pipe > waiters, socket waiters (especially accept), etc. Yea, and my following patches are for socket waiters. > > Do you have any measurements which showing the LIFO mode performing > better than FIFO, and by how much? > I didn't do any test yet. But some work done by LSE project years ago showed that it is better. http://lse.sourceforge.net/io/aionotes.txt " Also in view of better cache utilization the wake queue mechanism is LIFO by default. (A new exclusive LIFO wakeup option has been introduced for this purpose)" -- Regards， Changli Gao(xiaosuo@gmail.com) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/