Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754442AbYFWV2x (ORCPT ); Mon, 23 Jun 2008 17:28:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752552AbYFWV2p (ORCPT ); Mon, 23 Jun 2008 17:28:45 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:40315 "EHLO e4.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752526AbYFWV2o (ORCPT ); Mon, 23 Jun 2008 17:28:44 -0400 Subject: Re: [PATCH -tip-rcu] Make rcutorture more vicious: make quiescent rcutorture less power-hungry From: Darren Hart To: paulmck@linux.vnet.ibm.com Cc: Arjan van de Ven , linux-kernel@vger.kernel.org, mingo@elte.hu, josh@freedesktop.org, niv@us.ibm.com, dino@in.ibm.com, akpm@linux-foundation.org, torvalds@linux-foundation.org, vegard.nossum@gmail.com, adobriyan@gmail.com, oleg@tv-sign.ru, bunk@kernel.org, rjw@sisk.pl In-Reply-To: <20080623201516.GC10595@linux.vnet.ibm.com> References: <20080618122144.GA27143@linux.vnet.ibm.com> <20080618162649.GA18326@linux.vnet.ibm.com> <20080622200638.GA25328@linux.vnet.ibm.com> <20080622131712.54ba732c@infradead.org> <1214243649.4440.10.camel@Aeon> <20080623110706.197f25b1@infradead.org> <1214251374.4440.48.camel@Aeon> <20080623201516.GC10595@linux.vnet.ibm.com> Content-Type: text/plain Date: Mon, 23 Jun 2008 21:28:51 +0000 Message-Id: <1214256531.4440.92.camel@Aeon> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1648 Lines: 41 On Mon, 2008-06-23 at 13:15 -0700, Paul E. McKenney wrote: > On Mon, Jun 23, 2008 at 08:02:54PM +0000, Darren Hart wrote: > > On Mon, 2008-06-23 at 11:07 -0700, Arjan van de Ven wrote: > > > On Mon, 23 Jun 2008 17:54:09 +0000 > > > Darren Hart wrote: > > > > > > > I'm a little concerned about how this will affect real-time > > > > performance, as queueing up lots of timers all at once can lead to > > > > long running timer expiration handlers. If just a schedule_timeout, > > > > I suppose we are only looking at a process wakeup, as opposed to a > > > > softirq context callback function? > > > > > > in reality, the time it takes to deliver the interrupt (including > > > waking the CPU up etc), is likely to be an order or two of magnitude > > > higher than this kind of code loop.... > > > > Sure, if we just look at one of them. Any idea how many such items > > we're looking at rounding up to fire at the same time? Is it dozens, > > hundreds, thousands? > > Hello, Darren, > > Wouldn't these timers be running at low priority, so that high-priority > realtime tasks would preempt them? The timers run from softirq context will run at the priority of the softirq, so it is configurable, and only tasks equal to or lower in priority to that should see direct effects. > > Thanx, Paul -- Darren Hart Real-Time Linux Team Lead IBM Linux Technology Center -- 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/