[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4846ED88.6040100@qualcomm.com>
Date: Wed, 04 Jun 2008 12:31:20 -0700
From: Max Krasnyansky <maxk@...lcomm.com>
To: Paul Jackson <pj@....com>
CC: andi@...stfloor.org, ioe-lkml@...eria.de, sivanich@....com,
a.p.zijlstra@...llo.nl, linux-kernel@...r.kernel.org,
kernel@...ivas.org, dfults@....com, devik@....cz, dino@...ibm.com,
emmanuel.pacaud@...v-poitiers.fr, deweerdt@...e.fr, mingo@...e.hu,
colpatch@...ibm.com, nickpiggin@...oo.com.au, rostedt@...dmis.org,
oleg@...sign.ru, paulmck@...ibm.com, menage@...gle.com,
rddunlap@...l.org, suresh.b.siddha@...el.com, tglx@...utronix.de
Subject: Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may
have realtime uses)
Paul Jackson wrote:
> Max wrote:
>> You do not even need to replace /sbin/init for this, no ?
>> Simply installing custom
>> /etc/init.d/create_cpusets
>
> That can ensure that the deamons that init starts later
> on placed, but it doesn't ensure that the glibc pages that
> init (and the shell it spawned to run 'create_cpusets')
> are placed.
Ah, I missed the memory placement part. As far cpu placement goes the result
would be equivalent but not for memory.
btw Are you guys using some kind of castrated, statically linked shell to run
that script ? Otherwise regular shell and friends will suck in the same glibc
pages as the regular init would.
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists