mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Max Krasnyanskiy <maxk@qualcomm.com>
Cc: Ingo Oeser <ioe-lkml@rameria.de>,
	Dimitri Sivanich <sivanich@sgi.com>,
	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>,
	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: Wed, 4 Jun 2008 11:18:39 +1000	[thread overview]
Message-ID: <200806041118.40675.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <4845D825.6000403@qualcomm.com>

On Wednesday 04 June 2008 09:47, Max Krasnyanskiy wrote:
> >> 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=.

For your case, that's probably the best way to solve it, yes.


> 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.

When you bring a CPU online, in theory the sched domains should get
set up for them, so you should start seeing processes get migrated
onto it, and with them timers work queues etc.

If you have irqbalanced running, it probably migrates irqs onto them
as well if it needs to.

  parent reply	other threads:[~2008-06-04  1:19 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-02  2:30 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
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 [this message]
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=200806041118.40675.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --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=maxk@qualcomm.com \
    --cc=menage@google.com \
    --cc=mingo@elte.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®