Thank you for the answer.
On Oct 19, 2012, at 6:24 PM, Peter Zijlstra wrote:
> its a quick hack similar to existing hacks done for rt, preferably we'd
> do smarter things though.
If you have any ideas how to fix this in a better way, please share.
--
To unsubscribe from this list: send the line
On Thu, 2012-10-18 at 11:32 +0400, Vladimir Davydov wrote:
>
> 1) Do you agree that the problem exists and should be sorted out?
This is two questions.. yes it exists, I'm absolutely sure I pointed it
out as soon as people even started talking about this nonsense (bw
cruft).
Should it be sorted,
There is an error in the test script: I forgot to initialize cpuset.mems of
test cgroups - without it it is impossible to add a task into a cpuset cgroup.
Sorry for that.
Fixed version of the test script is attached.
On Oct 18, 2012, at 11:32 AM, Vladimir Davydov wrote:
> If several tasks in d
If several tasks in different cpu cgroups are contending for the same resource
(e.g. a semaphore) and one of those task groups is cpu limited (using cfs
bandwidth control), the priority inversion problem is likely to arise: if a cpu
limited task goes to sleep holding the resource (e.g. trying to ta
4 matches
Mail list logo
