Bug 5877
Summary: | Suspected scheduling starvation | ||
---|---|---|---|
Product: | Process Management | Reporter: | Heikki Orsila (heikki.orsila) |
Component: | Scheduler | Assignee: | Con Kolivas (bugzilla) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | bugzilla |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.15-rc7 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
sched improve task noninteractive patch
2.6.15 interactivity rollup 2.6.15-rc7 interbench results without any patch 2.6.15 interbench results with the second patch applied |
Description
Heikki Orsila
2006-01-12 11:59:40 UTC
This looks like it is related to the TASK_NONINTERACTIVE flag for pipes. Can you check to see if the problem existed prior to this change? 2.6.12 had the new fatter deeper pipes but did not have the TASK_NONINTERACTIVE flag if I recall correctly. It seems I don't get any underruns on 2.6.12, which is great. I hope you can fix this problem soon. Created attachment 7007 [details]
sched improve task noninteractive patch
Alter the activated mechanism to count all sleep time in a linear fashion and
move the TASK_NONINTERACTIVE flagged tasks to gain sleep average from this
instead of no sleep average.
Please try the patch I attached here to see if it helps 2.6.15. Also I am interested in any detrimental interactivity effects of this patch. > Please try the patch I attached here to see if it helps 2.6.15. Also I
> am interested in any detrimental interactivity effects of this patch.
Do you have any tips what to test? Are there scheduling test suites?
I wrote an interactivity benchmark which covers some of the basics (interbench.kolivas.org). You can use this for some hard measurements. A lot is still up to you to test in your normal environment to see how smooth windows move about and audio and video plays back etc under your _normal_ workloads. I don't really care how it feels with 'make -j16' in the background because optimising for something like that is pointless and tends to favour unfair scheduling. I compiled 2.6.15 with your patch and I'm not getting any underruns anymore :) Created attachment 7008 [details]
2.6.15 interactivity rollup
Great. That patch was part of a series I'm working on to correct a few current
quirks. Can you test this rolled up patch which contains all those in the
series to ensure it still fixes your problem? You will need to back out the
previous patch first.
I'll try it in the evening. -> work I tested your newer patch too. It also worked well; no underruns. I will post interbench results later for 2.6.15-rc7 and 2.6.15-interactive-patch. Created attachment 7019 [details]
2.6.15-rc7 interbench results without any patch
Created attachment 7020 [details]
2.6.15 interbench results with the second patch applied
Here are both of the interbench results. The first one (2.6.15-rc7) is without
any patch, and the second one is with the second interactivity patch.
Thanks for the results. The changes are consistent with what we would expect, the heavy cpu interactive tasks (like X) suffer more under I/O load since these patches also increase the bonuses of I/O bound tasks (see the lkml thread). Ok these patches have been queued up for the next -mm so I'm marking this bug as fixed. The bug occurs with 2.6.16 too. Is this going to be fixed in the future? Is merging the 2.6.15 interactivity patch safe for 2.6.16? The patches were merged into -mm and thus are following the normal cycle for mainstream inclusion. They are in the -mm kernel as of then and I was planning on pushing them for 2.6.17. There are some changes in 2.6.16 that prevent the patch from applying cleanly. I closed this bug because a code fix was pushed to -mm and will eventually be merged upstream. Only reopen the bug if the problem is present in the current -mm kernel please. > I was planning on pushing them for 2.6.17
Thanks. Will it also be pushed into the new 2.6.16.* series?
No, because it was too big a change to go into 2.6.16, therefore it is definitely too big a change to go into 2.6.16.x For convenience I've posted a patch for 2.6.16 here: http://ck.kolivas.org/patches/interactivity/2.6.16-O22.1int.patch > No, because it was too big a change to go into 2.6.16, therefore it is > definitely too big a change to go into 2.6.16.x According to this: http://lkml.org/lkml/2005/12/3/55 2.6.16.x might be maintained for as long as 2 to 3 years. Having a deficient scheduler for that long would tremendously decrease usability of that kernel series. No doubt this will cause more bug reports and I dislike the idea of work-arounding this problem in the application. Being maintained doesn't make it the "current" stable kernel. I'm not going to argue the development model here. Feel free to debate this issue in the appropriate place. |