Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754966AbYFLIJh (ORCPT ); Thu, 12 Jun 2008 04:09:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751459AbYFLIJX (ORCPT ); Thu, 12 Jun 2008 04:09:23 -0400 Received: from embla.aitel.hist.no ([158.38.50.22]:37097 "EHLO embla.aitel.hist.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751248AbYFLIJW (ORCPT ); Thu, 12 Jun 2008 04:09:22 -0400 Message-ID: <4850D9AC.3040706@aitel.hist.no> Date: Thu, 12 Jun 2008 10:09:16 +0200 From: Helge Hafting User-Agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420) MIME-Version: 1.0 To: Leon Woestenberg CC: 7eggert@gmx.de, Peter Zijlstra , Jakub Jozwicki , linux-kernel@vger.kernel.org, Robert Hancock Subject: Re: sched_yield() on 2.6.25 References: <20080611152807.0682218F62@be1.lrz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2401 Lines: 55 Leon Woestenberg wrote: [...] > That's not the definition of sched_yield(). See the earlier emails, > and the quote above. > > As the code after sched_yield() has to be executed the thread will be > rescheduled soon (or even immediately) anyway. > > The users not understanding the limited scope where sched_yield() > behaves deterministicly, seem to think that _yield() will yield() AND > lower the thread's dynamic priority for SCHED_OTHER. Is downgrading > the dynamic priority a behavioral option? > That can be done of course, but that too will cause breakage. Consider a multithreaded app mistakenly relying on sched_yield. Priority downgrading might work really well as long as this app runs alone, the yielding thread stops and the others progress, so sched_yield works for "userspace locking". And it works so well, the app uses it a lot. Then someone recompiles the distro or runs some other kinds of cpu hogs that drives the load well above 1. Users expect the apps to run a little slower because of this. But a load of 5 still ought to give you 1/5 of the cpu - and with today's CPU's that might still be better than a 5-year old machine. Interactive software should almost not notice, as it don't use the cpu that much anyway - and it gets priority over cpu hogs when it occationally needs to do something. But now this multithreaded app practically stops because it yields a lot - an everytime it lowers its priority below not only its own other threads, but below the various cpu hogs as well. (Compilers gets dynamic boosts too, as they wait a little for the disk now and then. A parallel compile still keeps the total load high.) I remember seeing openoffice taking 5min to start some years ago, with a compile going on. Of course there were other problems like swapping and a smaller computer, but other apps were merely slow, not that glacial. > On the other hand, I don't think anything should encourage the use of > sched_yield() outside of the rare SCHED_FIFO/RR case. > Exactly. There seems to be no way to make sched_yield work "as expected" for all the ways it is abused, so better use something else. Helge Hafting -- 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/