Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757390AbXJAWTS (ORCPT ); Mon, 1 Oct 2007 18:19:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753671AbXJAWTL (ORCPT ); Mon, 1 Oct 2007 18:19:11 -0400 Received: from mail1.webmaster.com ([216.152.64.169]:3234 "EHLO mail1.webmaster.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753578AbXJAWTJ (ORCPT ); Mon, 1 Oct 2007 18:19:09 -0400 From: "David Schwartz" To: "Arjan van de Ven" Cc: "Ingo Molnar" , Subject: RE: Network slowdown due to CFS Date: Mon, 1 Oct 2007 15:17:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20071001125350.055ef9bb@laptopd505.fenrus.org> X-Authenticated-Sender: joelkatz@webmaster.com X-Spam-Processed: mail1.webmaster.com, Mon, 01 Oct 2007 15:18:13 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 206.171.168.138 X-Return-Path: davids@webmaster.com X-MDaemon-Deliver-To: linux-kernel@vger.kernel.org Reply-To: davids@webmaster.com X-MDAV-Processed: mail1.webmaster.com, Mon, 01 Oct 2007 15:18:14 -0700 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1852 Lines: 41 Arjan van de Ven wrote: > > It can occasionally be an optimization. You may have a case where you > > can do something very efficiently if a lock is not held, but you > > cannot afford to wait for the lock to be released. So you check the > > lock, if it's held, you yield and then check again. If that fails, > > you do it the less optimal way (for example, dispatching it to a > > thread that *can* afford to wait). > at this point it's "use a futex" instead; once you're doing system > calls you might as well use the right one for what you're trying to > achieve. There are two answers to this. One is that you sometimes are writing POSIX code and Linux-specific optimizations don't change the fact that you still need a portable implementation. The other answer is that futexes don't change anything in this case. In fact, in the last time I hit this, the lock was a futex on Linux. Nevertheless, that doesn't change the basic issue. The lock is locked, you cannot afford to wait for it, but not getting the lock is expensive. The solution is to yield and check the lock again. If it's still held, you dispatch to another thread, but many times, yielding can avoid that. A futex doesn't change the fact that sometimes you can't afford to block on a lock but nevertheless would save significant effort if you were able to acquire it. Odds are the thread that holds it is about to release it anyway. That is, you need something in-between "non-blocking trylock, fail easily" and "blocking lock, do not fail", but you'd rather make forward progress without the lock than actually block/sleep. DS - 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/