On Tue, 8 May 2012, Gilad Ben-Yossef wrote:

My line of thought was that if we explicitly choose a scapegoat cpu we
and the user need to manage this - such as worry about what happens if
the scapegoats is offlines and let the user explicitly designate the
scapegoat cpu thus creating another knob, and worrying about what
happens if the user designate such a cpu but then it goes offlines...

The scapegoat can be chosen on boot. One can f.e. create a file in

/sys/device/syste/cpu called "scapegoat" which contains the number of the
processor chosen. Then one can even write a userspace daemon to automatize
the moving of the processing elsewhere. Could be integrated into something
horrible like irqbalance f.e.

I figured the user needs to worry about other unbounded work items
anyway if he cares about where such things are run in the general case,
but using isolcpus for example.

True. So the scapegoat heuristic could be to pick the first
unisolated cpu.

The same should be doable with cpusets, except that right now we mark
unbounded workqueue worker threads as pinned even though they aren't. If
I understood the discussion, the idea is exactly to stop users from
putting these threads in non root cpusets. I am not 100% sure why..

Not sure that cpusets is a good thing to bring in here because that is an
optional feature of the kernel and tying basic functionality like this
to cpuset support does not sound right to me.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>