Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754300AbYHSLMV (ORCPT ); Tue, 19 Aug 2008 07:12:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752461AbYHSLMM (ORCPT ); Tue, 19 Aug 2008 07:12:12 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:45162 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752368AbYHSLML (ORCPT ); Tue, 19 Aug 2008 07:12:11 -0400 Date: Tue, 19 Aug 2008 13:11:52 +0200 From: Ingo Molnar To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Stefani Seibold , Dario Faggioli , Nick Piggin , Max Krasnyansky , Linus Torvalds , Thomas Gleixner Subject: Re: [PATCH 6/6] sched: disabled rt-bandwidth by default Message-ID: <20080819111152.GA8592@elte.hu> References: <20080819103301.787700742@chello.nl> <20080819103844.459178947@chello.nl> <20080819110557.GA18608@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080819110557.GA18608@elte.hu> User-Agent: Mutt/1.5.18 (2008-05-17) 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 Content-Length: 2105 Lines: 56 * Ingo Molnar wrote: > The fixes look good to me, but this enabling of infinite RT task > lockups is not an improvement. > > The thing is, i got far more bugreports about locked up RT tasks where > the lockup was unintentional, than real bugreports about anyone > _intending_ for the whole box to come to a grinding halt because a > high-prio RT tasks is monopolizing the CPU. > > In fact there's only been this artificial test so far. > > So could you please just increase the chunking to 10 seconds or so, > from the current 1 second? Anyone locking up the system for more than > 10 seconds via an RT task has to deal with many other issues already. > > I.e. keep the system borderline debuggable (up to 10 seconds delays > are _not_ nice so people will notice) - but it's still a marked > improvement from completly locked up desktops. > > And those who really need longer than 10 second periods can set it > higher, or even (if they want to live dangerously or run POSIX > conformance tests) make it infinite (set it to -1) - and will have to > deal with other things like the softlockup watchdog as well. > > Ok? ok - i've queued the fixes up in tip/sched/rt (not in tip/sched/urgent yet, they need a bit of test-time, but are potential v2.6.27 commits) - see the shortlog below. Ingo ------------------> Ingo Molnar (1): sched: set rt-bandwidth period from 1 second to 10 seconds Peter Zijlstra (5): sched: rt-bandwidth for user grouping interface sched: rt-bandwidth accounting fix sched: rt-bandwidth group disable fixes sched: extract walk_tg_tree() sched: rt-bandwidth fixes kernel/sched.c | 215 +++++++++++++++++++++++++++++------------------------ kernel/sched_rt.c | 16 ++-- kernel/user.c | 4 +- 3 files changed, 129 insertions(+), 106 deletions(-) -- 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/