lkml.org 
[lkml]   [2008]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses)
Date
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.


\
 
 \ /
  Last update: 2008-06-04 03:21    [W:0.135 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site