Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757425AbYFDUNr (ORCPT ); Wed, 4 Jun 2008 16:13:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751314AbYFDUNj (ORCPT ); Wed, 4 Jun 2008 16:13:39 -0400 Received: from wolverine01.qualcomm.com ([199.106.114.254]:34784 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751279AbYFDUNi (ORCPT ); Wed, 4 Jun 2008 16:13:38 -0400 X-IronPort-AV: E=McAfee;i="5200,2160,5310"; a="3682537" Message-ID: <4846F789.7050702@qualcomm.com> Date: Wed, 04 Jun 2008 13:14:01 -0700 From: Max Krasnyansky User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Peter Zijlstra CC: Dimitri Sivanich , linux-kernel@vger.kernel.org, Ingo Molnar , Nick Piggin , rostedt@goodmis.org, Oleg Nesterov , "Paul E. McKenney" , Paul Menage , "Randy.Dunlap" , suresh.b.siddha@intel.com Subject: Re: Stop machine threads are getting preemted by the rt period enforcement References: <20080601213019.14ea8ef8.pj@sgi.com> <20080602164203.GA2477@sgi.com> <48443E66.6060205@qualcomm.com> <20080602214151.GA7072@sgi.com> <48446D46.2010903@qualcomm.com> <20080603144010.GA25948@sgi.com> <20080604140036.GC18993@sgi.com> <4846D9FE.4030804@qualcomm.com> <1212603506.19205.2.camel@lappy.programming.kicks-ass.net> <4846DDC1.1050203@qualcomm.com> <1212605725.19205.17.camel@lappy.programming.kicks-ass.net> In-Reply-To: <1212605725.19205.17.camel@lappy.programming.kicks-ass.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1229 Lines: 31 Peter Zijlstra wrote: > On Wed, 2008-06-04 at 11:24 -0700, Max Krasnyansky wrote: >> Peter Zijlstra wrote: >>> On Wed, 2008-06-04 at 11:07 -0700, Max Krasnyansky wrote: >>>> Peter, Ingo, >>>> >>>> Take a look at the report below (came up during isolcpu= remove discussions). >>>> >>>> It looks like stop_machine threads are getting forcefully preempted because >>>> they exceed their RT quanta. It's strange because rt period is pretty long. >>>> But given that disabling rt period logic solves the issue the machine was not >>>> really stuck. >>> Yeah, I know, I'm already looking at this >> I see. Does it look like a bug in the rt period logic ? >> Or did the stop_machine thread really run for a long time (in the report that >> you got that is) ? > > looks like a fun race between refreshing the period and updating > cpu_online_map. Oh, I did not realize that rt period is a timer that iterates online cpus. I assumed that you do it in the scheduler tick or something. Max -- 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/