From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758221AbYEMOmw (ORCPT ); Tue, 13 May 2008 10:42:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751431AbYEMOmo (ORCPT ); Tue, 13 May 2008 10:42:44 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:38865 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750883AbYEMOmn (ORCPT ); Tue, 13 May 2008 10:42:43 -0400 Date: Tue, 13 May 2008 16:42:07 +0200 From: Ingo Molnar To: Matthew Wilcox Cc: Sven Wegener , Linus Torvalds , "Zhang, Yanmin" , Andi Kleen , LKML , Alexander Viro , Andrew Morton , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra Subject: Re: [git pull] scheduler fixes Message-ID: <20080513144207.GA4697@elte.hu> References: <20080511130226.GR19219@parisc-linux.org> <20080511132636.GA22878@parisc-linux.org> <20080511140017.GA2457@elte.hu> <20080511141818.GT19219@parisc-linux.org> <20080511144203.GB3220@elte.hu> <20080511144821.GW19219@parisc-linux.org> <20080511151909.GA3887@elte.hu> <20080511152942.GY19219@parisc-linux.org> <20080513141129.GC18798@elte.hu> <20080513142135.GF9324@parisc-linux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080513142135.GF9324@parisc-linux.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Matthew Wilcox wrote: > > a 50% AIM7 slowdown maybe? With the BKL being a spinlock again it > > doesnt matter much in practice though. > > You're not understanding me. This is completely inapplicable to the > BKL because only one task can be in wakeup at a time (due to it having > a maximum value of 1). There's no way to hit this race with the BKL. > The only kind of semaphore that can hit this race is the kind that can > have more than one wakeup in progress at a time -- ie one which can > have a value >1. Like completions and real counting semaphores. yes, but even for parallel wakeups for completions it's good in general to keep more tasks in flight than to keep less tasks in flight. Perhaps the code could throttle them to nr_cpus, but otherwise, as the BKL example has shown it (in another context), we do much better if we overload the scheduler (in which case it can and does batch intelligently) than if we try to second-guess it and under-load it and create lots of scheduling events. i'd agree with you that are no numbers available pro or contra, so you are right that my 50% point does not apply to your argument. > So the only thing worth talking about (and indeed, it's now entirely > moot) is what's the best way to solve this problem /for this kind of > semaphore/. it's not really moot in terms of improving the completions code i suspect? For XFS i guess performance matters. Ingo