All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Krasnyansky <maxk@qualcomm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Oeser <ioe-lkml@rameria.de>, Paul Jackson <pj@sgi.com>,
	linux-kernel@vger.kernel.org, Con Kolivas <kernel@kolivas.org>,
	"Derek L. Fults" <dfults@sgi.com>, devik <devik@cdi.cz>,
	Dimitri Sivanich <sivanich@sgi.com>,
	Dinakar Guniguntala <dino@in.ibm.com>,
	Emmanuel Pacaud <emmanuel.pacaud@univ-poitiers.fr>,
	Frederik Deweerdt <deweerdt@free.fr>, Ingo Molnar <mingo@elte.hu>,
	Matthew Dobson <colpatch@us.ibm.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	rostedt@goodmis.org, Oleg Nesterov <oleg@tv-sign.ru>,
	"Paul E. McKenney" <paulmck@us.ibm.com>,
	Paul Menage <menage@google.com>,
	"Randy.Dunlap" <rddunlap@osdl.org>,
	suresh.b.siddha@intel.com, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses)
Date: Mon, 02 Jun 2008 16:04:21 -0700	[thread overview]
Message-ID: <48447C75.8040203@qualcomm.com> (raw)
In-Reply-To: <1212446707.6269.26.camel@lappy.programming.kicks-ass.net>

Peter Zijlstra wrote:
> On Tue, 2008-06-03 at 00:35 +0200, Ingo Oeser wrote:
>> Hi Paul,
>>
>> in short: NAK!
>>
>> On Monday 02 June 2008, Paul Jackson wrote:
>>> (Aside to the RealTime folks -- is there a 'realtime'
>>> email list which I should include in this discussion?)
>>>
>>> The kernel has a "isolcpus=" kernel boot time parameter.  This
>>> parameter isolates CPUs from scheduler load balancing, minimizing the
>>> impact of scheduler latencies on realtime tasks running on those CPUs.
>> I used it to mask out a defect CPU on a 8-CPU node of a 
>> HPC-cluster at a customer site, until the $BIG_VENDOR 
>> sent a replacement. And to prove $BIG_VENDOR, that we actually
>> have a problem on THAT CPU.
>>
>> So I would really like to keep this fault isolation capability.
>> I made my customer happy with that.
>>
>> I wish Linux had more such "mask out bad hardware" features
>> to faciliate fault isolation and boot and runtime.
> 
> Yeah - except that its not meant to be used as such - it will still
> brings the cpu up, and it is still usable for the OS.
> 
> So sorry, your abuse doesn't make for a case to keep this abomination.

Ingo, I just wanted to elaborate on what Peter is saying. That CPU will still
have to be _booted_ properly. It may be used for hard- and soft- interrupt
processing, workqueues (internal kernel queuing mechanism) and kernel timers.

In your particular case you're much much much better off with doing
	echo 0 > /sys/devices/system/cpuN/online
either during initrd stage or as a first init script.
That way bad cpu will be _completely_ disabled.

Max

  reply	other threads:[~2008-06-02 23:04 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-02  2:30 Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses) Paul Jackson
2008-06-02 16:42 ` Dimitri Sivanich
2008-06-02 18:39   ` Max Krasnyansky
2008-06-02 21:41     ` Dimitri Sivanich
2008-06-02 21:59       ` Max Krasnyansky
2008-06-03 14:40         ` Dimitri Sivanich
2008-06-03 17:57           ` Max Krasnyanskiy
2008-06-04 14:00           ` Dimitri Sivanich
2008-06-04 18:07             ` Stop machine threads are getting preemted by the rt period enforcement Max Krasnyansky
2008-06-04 18:18               ` Peter Zijlstra
2008-06-04 18:24                 ` Max Krasnyansky
2008-06-04 18:55                   ` Peter Zijlstra
2008-06-04 20:14                     ` Max Krasnyansky
2008-06-02 22:35 ` Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses) Ingo Oeser
2008-06-02 22:45   ` Peter Zijlstra
2008-06-02 23:04     ` Max Krasnyansky [this message]
2008-06-02 23:55       ` Ingo Oeser
2008-06-03  3:32         ` Max Krasnyansky
2008-06-03 23:47           ` Max Krasnyanskiy
2008-06-04  0:41             ` Paul Jackson
2008-06-04  4:32               ` Max Krasnyansky
2008-06-04  4:47                 ` Paul Jackson
2008-06-04 12:18                 ` Andi Kleen
2008-06-04 17:41                   ` Paul Jackson
2008-06-04 18:29                     ` Max Krasnyansky
2008-06-04 18:56                       ` Peter Zijlstra
2008-06-04 19:34                         ` Max Krasnyansky
2008-06-04 18:58                       ` Paul Jackson
2008-06-04 19:31                         ` Max Krasnyansky
2008-06-04 19:37                           ` Paul Jackson
2008-06-04 19:45                             ` Max Krasnyansky
2008-06-04 20:05                       ` Andi Kleen
2008-06-04 20:23                         ` Paul Jackson
2008-06-04 20:03                     ` Andi Kleen
2008-06-04 20:16                       ` Paul Jackson
2008-06-04 20:33                         ` Andi Kleen
2008-06-04 20:38                           ` Paul Jackson
2008-06-04 21:16                             ` Max Krasnyansky
2008-06-04 21:17                               ` Paul Jackson
2008-06-04 21:20                                 ` Max Krasnyansky
2008-06-04 21:26                                   ` Paul Jackson
2008-06-04  1:18             ` Nick Piggin
2008-06-04  3:00               ` Max Krasnyansky
2008-06-04 16:18             ` Ingo Oeser
2008-06-04 17:47               ` Max Krasnyansky
2008-06-03  6:03     ` Nick Piggin
2008-06-04  9:58       ` Mark Hounschell
2008-06-04 17:26         ` Paul Jackson
2008-06-04 21:00           ` Mark Hounschell
2008-06-04 21:03             ` Paul Jackson
2008-06-04 19:26         ` Max Krasnyansky
2008-06-04 20:25           ` Peter Zijlstra
2008-06-04 21:44             ` Michael Trimarchi
2008-06-04 21:52               ` Peter Zijlstra
2008-06-05 11:16                 ` Michael Trimarchi
2008-06-05 12:07                   ` Peter Zijlstra
2008-06-05 14:57                     ` Michael Trimarchi
2009-05-08  2:48               ` GeunSik Lim
2008-06-05 11:44             ` Mark Hounschell
2008-06-06 22:28               ` Max Krasnyanskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48447C75.8040203@qualcomm.com \
    --to=maxk@qualcomm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=colpatch@us.ibm.com \
    --cc=devik@cdi.cz \
    --cc=deweerdt@free.fr \
    --cc=dfults@sgi.com \
    --cc=dino@in.ibm.com \
    --cc=emmanuel.pacaud@univ-poitiers.fr \
    --cc=ioe-lkml@rameria.de \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=oleg@tv-sign.ru \
    --cc=paulmck@us.ibm.com \
    --cc=pj@sgi.com \
    --cc=rddunlap@osdl.org \
    --cc=rostedt@goodmis.org \
    --cc=sivanich@sgi.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.