Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755984AbXJAW5Y (ORCPT ); Mon, 1 Oct 2007 18:57:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751917AbXJAW5S (ORCPT ); Mon, 1 Oct 2007 18:57:18 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:49341 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751365AbXJAW5R (ORCPT ); Mon, 1 Oct 2007 18:57:17 -0400 Date: Mon, 1 Oct 2007 15:55:30 -0700 From: Arjan van de Ven To: davids@webmaster.com Cc: "Ingo Molnar" , Subject: Re: Network slowdown due to CFS Message-ID: <20071001155530.5661fdef@laptopd505.fenrus.org> In-Reply-To: References: <20071001153529.7c669c7a@laptopd505.fenrus.org> Organization: Intel X-Mailer: Claws Mail 3.0.1 (GTK+ 2.12.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1781 Lines: 41 On Mon, 1 Oct 2007 15:44:09 -0700 "David Schwartz" wrote: > > > yielding IS blocking. Just with indeterminate fuzzyness added to > > it.... > > Yielding is sort of blocking, but the difference is that yielding > will not idle the CPU while blocking might. not really; SOMEONE will make progress, the one holding the lock. Granted, he can be on some other cpu, but at that point all yielding gets you is a bunch of cache bounces. >Yielding is sometimes > preferable to blocking in a case where the thread knows it can make > forward progress even if it doesn't get the resource. (As in the > examples I explained.) that's also what trylock is for... as well as spinaphores... (you can argue that futexes should be more intelligent and do spinaphore stuff etc... and I can buy that, lets improve them in the kernel by any means. But userspace yield() isn't the answer. A yield_to() would have been a ton better (which would return immediately if the thing you want to yield to is running already somethere), a blind "yield" isn't, since it doesn't say what you want to yield to. Note: The answer to "what to yield to" isn't "everything that might want to run"; we tried that way back when the 2.6.early scheduler was designed and that turns out to not be what people calling yield expected.. (it made their things even slower than they thought). So they want "yield to" semantics, without telling the kernel what they want to yield to, and complain if the kernel second-guesses wrongly.... not a good api. - 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/