Messages in this thread | | | Date | Fri, 25 Feb 2011 12:46:16 +0100 | From | Dominik Klein <> | Subject | Re: Is it a workqueue related issue in 2.6.37 (Was: Re: [libvirt] blkio cgroup [solved]) |
| |
Hi
>> This was taken with 2.6.37 plus the patch you mentioned on a Dell R815 >> with 2 12 core AMD Opteron 6174 CPUs. If you need any more information, >> please let me know. > > Hmmm... well, I have no idea what you were trying to do
Long story short: I have a couple of virtual machines. Some of them have blkio throttle configured, some don't. To simulate whether the throttling works, I start dd if=/dev/zero of=testfile bs=1M count=1500 in each guest simultaneously.
The result is that from that point, no i/o is happening any more. You see the result in the trace.
With 2.6.37 (also tried .1 and .2) it does not work but end up like I documented. With 2.6.38-rc1, it does work. With deadline scheduler, it also works in 2.6.37.
I am in bisect run 2 currently to find the changeset that fixed it.
Will let you know as soon as I do.
Regards Dominik
ps. I am by no means a kernel hacker and none of the rest of your email made any sense to me. Sorry.
> but here are > some info which might be helpful. > > * queue_work happens when the work item is queued. > > * activate_work happens when the work item becomes eligible for > execution. e.g. If the workqueue's @max_active is limited and > maximum number of work items are already in flight, a new item will > only get activated after one of the in flight ones retires. > > * execute_start marks the actual starting of execution. > > * execute_end marks the end of execution. > > So, I would look for the matching work function and then try to follow > what happens to it after being scheduled and if it doesn't get > executed what's going on with the target workqueue. > > Thanks.
| |