Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934298AbXEHHRu (ORCPT ); Tue, 8 May 2007 03:17:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755512AbXEHHRs (ORCPT ); Tue, 8 May 2007 03:17:48 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:56146 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755470AbXEHHRr (ORCPT ); Tue, 8 May 2007 03:17:47 -0400 Date: Tue, 08 May 2007 16:16:06 +0900 Message-ID: <87irb3g4zt.wl%takeuchi_satoru@jp.fujitsu.com> From: Satoru Takeuchi To: vatsa@in.ibm.com Cc: Satoru Takeuchi , Rusty Russell , Linux Kernel , Zwane Mwaikambo , Nathan Lynch , Joel Schopp , Ashok Raj , Heiko Carstens , Gautham R Shenoy , Ingo Molnar , paulmck@us.ibm.com Subject: Re: [BUG] cpu-hotplug: Can't offline the CPU with naughty realtime processes In-Reply-To: <20070508041033.GB25030@in.ibm.com> References: <87bqgxrlky.wl%takeuchi_satoru@jp.fujitsu.com> <1178545373.28438.7.camel@localhost.localdomain> <877irkrq8a.wl%takeuchi_satoru@jp.fujitsu.com> <1178593345.28438.29.camel@localhost.localdomain> <874pmoro1c.wl%takeuchi_satoru@jp.fujitsu.com> <20070508041033.GB25030@in.ibm.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2048 Lines: 46 At Tue, 8 May 2007 09:40:33 +0530, Srivatsa Vaddagiri wrote: > > On Tue, May 08, 2007 at 12:29:19PM +0900, Satoru Takeuchi wrote: > > > We used to be able to create kernel threads higher than any userspace > > > priority. If this is no longer true, I think that's OK: equal priority > > > still means we'll get scheduled, right? > > > > IF SCHED_RR, yes. However, if SCHED_FIFO, no. Such process doen't have timeslice > > and only relinquish CPU time voluntarily. > > yeah ..this is truly a problem if SCHED_FIFO user-space cpu hog task is > running at MAX_USER_RT_PRIO (which happens to be same as max real-time > priority kernel threads can attain - MAX_RT_PRIO). > > One option is to make MAX_USER_RT_PRIO < MAX_RT_PRIO. I am not sure what > semantics that will break (perhaps the real-time folks can clarify > that). Sometimes I wonder at prio_array. It has 140 entries(from 0 to 139), and the meaning of each entry is as follows, I think. +-----------+-----------------------------------------------+ | index | usage | +-----------+-----------------------------------------------+ | 0 - 98 | RT processes are here. They are in the entry | | | whose index is 99 - sched_priority. | +-----------+-----------------------------------------------+ | 99 | No one use it? CMIIW. | +-----------+-----------------------------------------------+ | 100 - 139 | Ordinally processes are here. They are in the | | | entry whose index is (nice+120) +/- 5 | +-----------+-----------------------------------------------+ What's the purpose of the prio_array[99]? Once I exlore source tree briefly and can't found any kernel thread which uses this entry. Does anybody know? Regards, Satoru - 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/