Paul Jackson wrote:
quoted text
> 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).

Max

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