All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Krasnyanskiy <maxk@qualcomm.com>
To: Ingo Oeser <ioe-lkml@rameria.de>, Dimitri Sivanich <sivanich@sgi.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	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>,
	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: Tue, 03 Jun 2008 16:47:49 -0700	[thread overview]
Message-ID: <4845D825.6000403@qualcomm.com> (raw)
In-Reply-To: <4844BB41.7000605@qualcomm.com>

>> I would really appreciate some way to keep the kernel from using 
>> a CPU at all to do fault isolation. If possible not even booting it.
> How does isolcpu= boot option helps in this case ?
> I suppose the closes option is maxcpus=. We can probably add ignorecpus= or
> something to handle your use case but it has nothing to do with isolcpus=.

btw Ingo, I just realized that maxcpu= option is exactly what you need.
Here is how you can use it.
Boot your system with maxcpus=1. That way the kernel will only bring up 
processor 0. I'm assuming cpu0 is "good" otherwise your system is totally 
busted :). Other cpus will stay off-line and will not be initialized.
Then once the system boots you can selectively bring "good" processors online 
by doing
	echo 1 > /sys/devices/system/cpu/cpuN/online

This actually solves the case you're talking about (ie ignoring bad 
processors) instead of partially covering it with isolcpus=.

Dimitri, you can probably use that too. ie Boot the thing with most CPUs 
offline and then bring them online. That way you'll know for sure that no 
timers, works, hard-/soft-irqs, etc are running on them.

So I expect two ACKs for isolcpu= removal from both of you, in bold please :)

Max

  reply	other threads:[~2008-06-03 23:48 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
2008-06-02 23:55       ` Ingo Oeser
2008-06-03  3:32         ` Max Krasnyansky
2008-06-03 23:47           ` Max Krasnyanskiy [this message]
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=4845D825.6000403@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.