Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755234AbYH1Qav (ORCPT ); Thu, 28 Aug 2008 12:30:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750828AbYH1Qan (ORCPT ); Thu, 28 Aug 2008 12:30:43 -0400 Received: from one.firstfloor.org ([213.235.205.2]:47343 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751127AbYH1Qam (ORCPT ); Thu, 28 Aug 2008 12:30:42 -0400 Date: Thu, 28 Aug 2008 18:33:19 +0200 From: Andi Kleen To: Ingo Molnar Cc: Max Krasnyansky , Andi Kleen , Peter Zijlstra , Nick Piggin , Thomas Gleixner , "linux-kernel@vger.kernel.org" , Stefani Seibold , Dario Faggioli , Linus Torvalds Subject: Re: [PATCH 6/6] sched: disabled rt-bandwidth by default Message-ID: <20080828163318.GR26610@one.firstfloor.org> References: <20080819103301.787700742@chello.nl> <874p57s873.fsf@basil.nowhere.org> <200808272008.16106.nickpiggin@yahoo.com.au> <20080828105408.GA4488@elte.hu> <20080828110923.GL26610@one.firstfloor.org> <1219922353.6443.14.camel@twins> <20080828115035.GM26610@one.firstfloor.org> <48B6CFFD.2050801@qualcomm.com> <20080828162548.GA3826@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080828162548.GA3826@elte.hu> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1463 Lines: 38 On Thu, Aug 28, 2008 at 06:25:48PM +0200, Ingo Molnar wrote: > > * Max Krasnyansky wrote: > > > Andi Kleen wrote: > >> On Thu, Aug 28, 2008 at 01:19:13PM +0200, Peter Zijlstra wrote: > >>> On Thu, 2008-08-28 at 13:09 +0200, Andi Kleen wrote: > >>>>> Even if the system has multiple CPUs, and even if just a single CPU is > >>>>> fully utilized by an RT task, without the rt-limit the system will still > >>>>> lock up in practice due to various other factors: workqueues and tasks > >>>>> being 'stuck' on CPUs that host an RT hog. > >>>> The load balancer will not notice that a particular CPU is busy > >>>> with real time tasks? > >>> Not currently, working on that though. > >> > >> I wonder if it would make sense to break affinities in extreme case? > >> With that even the workqueues would work again. > > > > Please lets not break affinity :). > > correct, breaking affinity is a rather stupid idea. Ok let's remove cpu hotunplug then. Probably nobody uses it anyways @) Seriously cpu affinity on all non BP CPU is currently broken on every suspend to RAM, doing it in a few more cases when it makes the system more robust is unlikely to hurt anybody. -Andi -- ak@linux.intel.com -- 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/