[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4537CC1E.60204@yahoo.com.au>
Date: Fri, 20 Oct 2006 05:03:58 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Paul Jackson <pj@....com>
CC: akpm@...l.org, mbligh@...gle.com, menage@...gle.com,
Simon.Derr@...l.net, linux-kernel@...r.kernel.org, dino@...ibm.com,
rohitseth@...gle.com, holt@....com, dipankar@...ibm.com,
suresh.b.siddha@...el.com
Subject: Re: [RFC] cpuset: add interface to isolated cpus
Paul Jackson wrote:
>>>So ... where should it be done?
>>
>>sched.c I suppose.
>
>
> Are we discussing where the implementing code should go,
> or where the isolated cpu map special file should be
> exposed to user space?
Both?
> And you didn't answer my other questions, such as:
> 1) If your other patch to manipulate sched domains
> has code that belongs in kernel/cpuset.c, and
> special files that belong in /dev/cpuset, why
> shouldn't this one naturally go in the same places?
Because they are cpuset specific. This is not.
> 2) Why ... why? What would be better about sched.c
> and what's wrong with where it is (the code and
> the exposed file)?
Because it is not specific to CONFIG_CPUSETS. People who
don't configure CONFIG_CPUSETS may still want to change
isolcpus at runtime.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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