max_cpus Maximum number of CPUs to use.
Specify the maximum number of processors that a SMPkernel
should use, even if there are more processors present in the system.
isolcpus Isolate CPUs from the kernel scheduler.
Remove the specified CPUs, as defined by the cpu_number values,
from the general kernel SMPbalancing and scheduler algroithms.
The only way to move a process onto or off an “isolated” CPU is
via the CPU affinity syscalls. cpu_number begins at 0, so the
maximum value is one less than the number of CPUs on the
This option is the preferred way to isolate CPUs. The alternative,
manually setting the CPU mask of all tasks in the system, can cause
problems and suboptimal load-balancer performance.
Re: Inquiry: Should we remove "isolcpus= kernel boot option? (mayhave realtime uses)
To bring cpuN offline
echo 0 > /sys/devices/system/cpu/cpuN/online
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
(Following is talking about the altitude that kernel treat "unused" functions)
A key reason that Linux has succeeded is that it actively seeks to work
for a variety of people, purposes and products. One operating system is
now a strong player in the embedded market, the real time market, and
the High Performance Computing market, as well as being an important
player in a variety of other markets. That's a rather stunning success.
If you went to your local grocery store with your (if you have one)
young child, and found that they had no Lucky Charms breakfast cereal
(your childs favorite) you would not be pleased if the store manager
tried to sell you Fruit Loops instead ... just as much sugar and food
If we have features that seem to duplicate functionality, in a
different way, and that aren't causing us substantial grief to
maintain, and that aren't significantly hurting our performance or
robustness or security or seriously getting in the way of further
development, then we usually leave those features in.
Please understand, Max, that for every kernel hacker working in this
corner of the Linux kernel, there are a hundred or a thousand users
depending on what we do, and who will have to adapt to any incompatible
changes we make. If we save ourselves an hour by removing "unnecessary"
features, we can cost a hundred others each some time adapting to this
change. A few of those others may get hit for substantial effort, if
the change catches them unawares at the wrong time and place.
As good citizens of the universe, we should seek to optimize the
aggregate effort we spend to obtain a particular level of quality and
Saving yourself an hour while you cost a hundred others ten minutes
each is not a net gain. Sometimes this means not enforcing a "one way,
and one way only, to do any given task." I wouldn't go as far as Perl
does in this regard, but we do run a more polyglot product than say
Try thinking a little more like a WalMart product manager than a
Ferrari designer. If it is currently selling to our customers, and if
we can fit it into our supply and distribution chain, and if we can
continue to make an adequate profit per foot of shelf space, then
continue to buy it, stock it, ship it, and sell it.