Re: [PATCH] sched: Give cpusets exclusive control over scheddomains (ie remove cpu_isolated_map)

[Peter Zijlstra]

On Sat, 2008-05-31 at 12:12 -0700, Max Krasnyansky wrote:
> 
> Paul Jackson wrote:
> > Max replied:
> >>> I did not see your reply.  Did you send it to me or lkml?
> >> http://marc.info/?l=linux-kernel&m=121207910616332&w=2
> > 
> > Ah - ok - I got that reply, and then lost track of it.  My bad.
> > 
> > Max wrote, in that earlier reply:
> >> Since we do not plan on supporting it I'd say lets get rid of it.
> > 
> > This doesn't make sense to me.  We don't just decree that we aren't
> > planning on supporting something that's already out there and being
> > used, and then remove it, on the grounds we aren't supporting it.
> > 
> > Faceless beauracracies can get away with that ... we can do better.
> 
> Ok. Let me ask you this. Would you be ok with a patch that exposes (via sysctl
> for example) scheduler balancer mask when cpusets are disabled ?
> In other words it will look something like this:
> - Rename cpu_isolated_map to sched_balancer_map
> - If cpusets are enabled
>   o balancer map is compiled out or a noop
>   o isolcpus= boot param is compiled out
> 
> - If cpusets are disabled
>   o balancer map can be changed via /proc/sys/kernel/sched_balancer_mask
>     writing to it rebuilds scheduler domains
>     cpus not in the mask will be put into NULL domain
>   o isolcpus= boot param is available for compatibility
> 
> Why do this ?
> Two reasons. It would not longer be a hack, it simply exposes scheduler
> feature that is not otherwise available without cpusets. And there is no
> conflict with sched domain management when cpusets are enabled. ie cpuset have
> exclusive control on domains).

Uhm, might be me but those two answers are not an answer to the question
posed.

Anyway, no, yuck! - let just get rid of it.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/