Re: [ck] Re: RSDL v0.31
On Mon, 2007-03-19 at 16:47 -0400, Bill Davidsen wrote: > Kasper Sandberg wrote: > > On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: > >> On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: > >> > >>> I'd recon KDE regresses because of kioslaves waiting on a pipe > >>> (communication with the app they're doing IO for) and then expiring. > >>> That's why splitting IO from an app isn't exactly smart. It should at > >>> least be ran in an another thread. > >> Hm. Sounds rather a lot like the... > >> X sucks, fix X and RSDL will rock your world. RSDL is perfect. > >> ...that I've been getting. > >> > > not really, only X sucks. KDE works atleast as good with rsdl as > > vanilla. i dont know how originally said kde works worse, wasnt it just > > someone that thought? > > > It was probably me, and I had the opinion that KDE is not as smooth as > GNOME with RSDL. I haven't had time to measure, but using for daily > stuff for about an hour each way hasn't changed my opinion. Every once > in a while KDE will KLUNK to a halt for 200-300ms doing mundane stuff > like redrawing a page, scrolling, etc. I don't see it with GNOME. umm, could you try to find something that always does it, so i can try to reproduce? cause i dont really hit any such thing, and i only have a 2ghz amd64 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Mon, 2007-03-19 at 16:47 -0400, Bill Davidsen wrote: Kasper Sandberg wrote: On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? It was probably me, and I had the opinion that KDE is not as smooth as GNOME with RSDL. I haven't had time to measure, but using for daily stuff for about an hour each way hasn't changed my opinion. Every once in a while KDE will KLUNK to a halt for 200-300ms doing mundane stuff like redrawing a page, scrolling, etc. I don't see it with GNOME. umm, could you try to find something that always does it, so i can try to reproduce? cause i dont really hit any such thing, and i only have a 2ghz amd64 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
Op Tuesday 20 March 2007, schreef Linus Torvalds:
> On Mon, 19 Mar 2007, Xavier Bestel wrote:
> > > >> Stock scheduler wins easily, no contest.
> > > >
> > > > What happens when you renice X ?
> > >
> > > Dunno -- not necessary with the stock scheduler.
> >
> > Could you try something like renice -10 $(pidof Xorg) ?
>
> Could you try something as simple and accepting that maybe this is a
> problem?
>
> Quite frankly, I was *planning* on merging RSDL very early after 2.6.21,
> but there is one thing that has turned me completely off the whole thing:
>
> - the people involved seem to be totally unwilling to even admit there
>might be a problem.
>
> This is like alcoholism. If you cannot admit that you might have a
> problem, you'll never get anywhere. And quite frankly, the RSDL proponents
> seem to be in denial ("we're always better", "it's your problem if the old
> scheduler works better", "just one report of old scheduler being better").
>
> And the thing is, if people aren't even _willing_ to admit that there may
> be issues, there's *no*way*in*hell* I will merge it even for testing.
> Because the whole and only point of merging RSDL was to see if it could
> replace the old scheduler, and the most important feature in that case is
> not whether it is perfect, BUT WHETHER ANYBODY IS INTERESTED IN TRYING TO
> FIX THE INEVITABLE PROBLEMS!
Con simply isn't available right now, but you're right. RSDL isn't ready yet,
imho, there seem to be some regressions (and I'm bitten by them, too). But if
con's past behaviour says anything about how he's going to behave in the
future (and according to my psych prof it's the most reliable predictor ;-)),
I'm pretty sure he'll jump on this when he's healthy again. He's gone through
great lengths to fix problems with staircase, no matter how obscure, so I see
no reason why he wouldn't do the same for RSDL... Though scheduler problems
can be extremely hard to reproduce on other hardware.
> See?
>
> Can you people not see that the way you're doing that "RSDL is perfect"
> chorus in the face of people who report problems, you're just making it
> totally unrealistic that it will *ever* get merged.
>
> So unless somebody steps up to the plate and actually *talks* about the
> problem reports, and admits that maybe RSDL will need some tweaking, I'm
> not going to merge it.
>
> Because there is just _one_ thing that is more important than code - and
> that is the willingness to fix the code...
>
> Linus
> ___
> http://ck.kolivas.org/faqs/replying-to-mailing-list.txt
> ck mailing list - mailto: [EMAIL PROTECTED]
> http://vds.kolivas.org/mailman/listinfo/ck
--
Disclaimer:
Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb.
Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat
ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf.
Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld.
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
pgp5Lq89fFLhw.pgp
Description: PGP signature
Re: [ck] Re: RSDL v0.31
Op Tuesday 20 March 2007, schreef Bill Davidsen: > Kasper Sandberg wrote: > > On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: > >> On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: > >>> I'd recon KDE regresses because of kioslaves waiting on a pipe > >>> (communication with the app they're doing IO for) and then expiring. > >>> That's why splitting IO from an app isn't exactly smart. It should at > >>> least be ran in an another thread. > >> > >> Hm. Sounds rather a lot like the... > >> X sucks, fix X and RSDL will rock your world. RSDL is perfect. > >> ...that I've been getting. > > > > not really, only X sucks. KDE works atleast as good with rsdl as > > vanilla. i dont know how originally said kde works worse, wasnt it just > > someone that thought? > > It was probably me, and I had the opinion that KDE is not as smooth as > GNOME with RSDL. I haven't had time to measure, but using for daily > stuff for about an hour each way hasn't changed my opinion. Every once > in a while KDE will KLUNK to a halt for 200-300ms doing mundane stuff > like redrawing a page, scrolling, etc. I don't see it with GNOME. yeah, here too... sometimes even longer (and I have a dualcore, 3gb ram, damnit!) -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html pgpTTtAuMOZKH.pgp Description: PGP signature
Re: [ck] Re: RSDL v0.31
Op Tuesday 20 March 2007, schreef Bill Davidsen: Kasper Sandberg wrote: On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? It was probably me, and I had the opinion that KDE is not as smooth as GNOME with RSDL. I haven't had time to measure, but using for daily stuff for about an hour each way hasn't changed my opinion. Every once in a while KDE will KLUNK to a halt for 200-300ms doing mundane stuff like redrawing a page, scrolling, etc. I don't see it with GNOME. yeah, here too... sometimes even longer (and I have a dualcore, 3gb ram, damnit!) -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html pgpTTtAuMOZKH.pgp Description: PGP signature
Re: [ck] Re: RSDL v0.31
Op Tuesday 20 March 2007, schreef Linus Torvalds: On Mon, 19 Mar 2007, Xavier Bestel wrote: Stock scheduler wins easily, no contest. What happens when you renice X ? Dunno -- not necessary with the stock scheduler. Could you try something like renice -10 $(pidof Xorg) ? Could you try something as simple and accepting that maybe this is a problem? Quite frankly, I was *planning* on merging RSDL very early after 2.6.21, but there is one thing that has turned me completely off the whole thing: - the people involved seem to be totally unwilling to even admit there might be a problem. This is like alcoholism. If you cannot admit that you might have a problem, you'll never get anywhere. And quite frankly, the RSDL proponents seem to be in denial (we're always better, it's your problem if the old scheduler works better, just one report of old scheduler being better). And the thing is, if people aren't even _willing_ to admit that there may be issues, there's *no*way*in*hell* I will merge it even for testing. Because the whole and only point of merging RSDL was to see if it could replace the old scheduler, and the most important feature in that case is not whether it is perfect, BUT WHETHER ANYBODY IS INTERESTED IN TRYING TO FIX THE INEVITABLE PROBLEMS! Con simply isn't available right now, but you're right. RSDL isn't ready yet, imho, there seem to be some regressions (and I'm bitten by them, too). But if con's past behaviour says anything about how he's going to behave in the future (and according to my psych prof it's the most reliable predictor ;-)), I'm pretty sure he'll jump on this when he's healthy again. He's gone through great lengths to fix problems with staircase, no matter how obscure, so I see no reason why he wouldn't do the same for RSDL... Though scheduler problems can be extremely hard to reproduce on other hardware. See? Can you people not see that the way you're doing that RSDL is perfect chorus in the face of people who report problems, you're just making it totally unrealistic that it will *ever* get merged. So unless somebody steps up to the plate and actually *talks* about the problem reports, and admits that maybe RSDL will need some tweaking, I'm not going to merge it. Because there is just _one_ thing that is more important than code - and that is the willingness to fix the code... Linus ___ http://ck.kolivas.org/faqs/replying-to-mailing-list.txt ck mailing list - mailto: [EMAIL PROTECTED] http://vds.kolivas.org/mailman/listinfo/ck -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html pgp5Lq89fFLhw.pgp Description: PGP signature
Re: [ck] Re: RSDL v0.31
Kasper Sandberg wrote: On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? It was probably me, and I had the opinion that KDE is not as smooth as GNOME with RSDL. I haven't had time to measure, but using for daily stuff for about an hour each way hasn't changed my opinion. Every once in a while KDE will KLUNK to a halt for 200-300ms doing mundane stuff like redrawing a page, scrolling, etc. I don't see it with GNOME. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
Kasper Sandberg wrote: On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? It was probably me, and I had the opinion that KDE is not as smooth as GNOME with RSDL. I haven't had time to measure, but using for daily stuff for about an hour each way hasn't changed my opinion. Every once in a while KDE will KLUNK to a halt for 200-300ms doing mundane stuff like redrawing a page, scrolling, etc. I don't see it with GNOME. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
Op Sunday 18 March 2007, schreef Radoslaw Szkodzinski: > On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote: > > Hm. Sounds rather a lot like the... > > X sucks, fix X and RSDL will rock your world. RSDL is perfect. > > ...that I've been getting. > > Blah. Nothing's perfect. Especially not computer programs. > > Still, it's not a smart decision on KDE's part. > It will break a lot of scheduling decisions, esp. you can't use IO > priorities. Well, if somebody could explain what they should do instead of what they're doing, I can contact them - the libraries for KDE 4 aren't in feature freeze yet (they will be, though) so they can solve the problem(s). The KIO infrastructure is ATM under a redesign, so please, if you know what they should do/are doing wrong, speak up! grtz Jos pgpurtRxp14WS.pgp Description: PGP signature
Re: [ck] Re: RSDL v0.31
On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote: Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. Blah. Nothing's perfect. Especially not computer programs. Still, it's not a smart decision on KDE's part. It will break a lot of scheduling decisions, esp. you can't use IO priorities. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On 3/18/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? Couldn't agree more, been using RSDL+KDE for a week now, and as far as I'm concerned I will be sticking with this until it goes to mainline, or mainline exhibits better behaviour. The fact of the matter is I was always unsure why windows 'feels' so much better than linux. RSDL makes it feel like windows, all the time, no matter what's going on. I'm really miffed when anyone talks about regressions, because I have scenarios that will completely lock up linux for 10s or so on my athlon 4200x2, due to [really] poorly designed apps that I need to run. RSDL seems to work right though it; it works faster, mouse feels better, browser scrolls smoothly, can't make the sound skip, video is fluid, opening a term is instant, boot up is faster, all which are a step up from mainline. That's the facts. IME I have seen nothing but good with RSDL. -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: > On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: > > > I'd recon KDE regresses because of kioslaves waiting on a pipe > > (communication with the app they're doing IO for) and then expiring. > > That's why splitting IO from an app isn't exactly smart. It should at > > least be ran in an another thread. > > Hm. Sounds rather a lot like the... > X sucks, fix X and RSDL will rock your world. RSDL is perfect. > ...that I've been getting. > not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? > -Mike > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sun, 2007-03-18 at 13:50 +0530, jimmy bahuleyan wrote: > maybe if it is possible to classify program behaviors that cause RSDL to > do bad (relatively) or the mainline scheduler to jitter, we could try > modifying the existing heuristics to get a better default scheduler. > > of course, it wouldn't be able to cater to all the workloads and would > meet everybody's definition of optimal. but getting close to optimal in > most cases should be a good enough goal for linux's default sched! > > i've been following this thread, and there's been many instances of > 'RSDL is gr8' and 'RSDL regresses'. > > maybe RSDL isn't the answer. maybe the current mainline sched isn't > either. but RSDL definitely has done *something* right. Agreed. > What i think is needed is 'why this works here' and 'how to get this > behavior to work with some other possibly conflicting but important > workloads'. > > (just my 2c :-) IMHO, that's worth more than 2c. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
Mike Galbraith wrote: > On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: > >> I'd recon KDE regresses because of kioslaves waiting on a pipe >> (communication with the app they're doing IO for) and then expiring. >> That's why splitting IO from an app isn't exactly smart. It should at >> least be ran in an another thread. > > Hm. Sounds rather a lot like the... > X sucks, fix X and RSDL will rock your world. RSDL is perfect. > ...that I've been getting. > > -Mike maybe if it is possible to classify program behaviors that cause RSDL to do bad (relatively) or the mainline scheduler to jitter, we could try modifying the existing heuristics to get a better default scheduler. of course, it wouldn't be able to cater to all the workloads and would meet everybody's definition of optimal. but getting close to optimal in most cases should be a good enough goal for linux's default sched! i've been following this thread, and there's been many instances of 'RSDL is gr8' and 'RSDL regresses'. maybe RSDL isn't the answer. maybe the current mainline sched isn't either. but RSDL definitely has done *something* right. What i think is needed is 'why this works here' and 'how to get this behavior to work with some other possibly conflicting but important workloads'. (just my 2c :-) -jb -- I am professionally trained in computer science, which is to say (in all seriousness) that I am extremely poorly educated. -- Joseph Weizenbaum - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: > On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: > > > I'd recon KDE regresses because of kioslaves waiting on a pipe > > (communication with the app they're doing IO for) and then expiring. > > That's why splitting IO from an app isn't exactly smart. It should at > > least be ran in an another thread. > > Hm. Sounds rather a lot like the... > X sucks, fix X and RSDL will rock your world. RSDL is perfect. > ...that I've been getting. P.S. For those folks who appear to think that I'm in love with mainline behavior and blissfully ignorant of it's shortcomings. http://lwn.net/Articles/176635/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: > I'd recon KDE regresses because of kioslaves waiting on a pipe > (communication with the app they're doing IO for) and then expiring. > That's why splitting IO from an app isn't exactly smart. It should at > least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On 3/18/07, Mike Galbraith <[EMAIL PROTECTED]> wrote: On Sun, 2007-03-18 at 07:47 +0100, Kasper Sandberg wrote: > > So neither does a good job with this load. > that sorely depends on what you mean by good job. > > It seems like what you call a good job is preserving the speed of the > gui(X + apps which uses it) at _ALL_ costs to other stuff. Wrong. I call a good job giving a _preference_ to the desktop. I call rigid fairness impractical for the desktop, and a denial of reality. My sound programs (audacity, non-RT) and mplayer disaggree with you. :-) Not to mention some more mundane stuff like Gajim. (no stall with its slow PyGTK UI on RSDL) (Hint: I'm using Xfce, not KDE) I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. A much better approach would be running IO in the context of the app, but using a common shared library. Also, Beryl works better with RSDL too. (blur doesn't "disable" itself sometimes - which is the result of a lag) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On 3/18/07, Mike Galbraith [EMAIL PROTECTED] wrote: On Sun, 2007-03-18 at 07:47 +0100, Kasper Sandberg wrote: So neither does a good job with this load. that sorely depends on what you mean by good job. It seems like what you call a good job is preserving the speed of the gui(X + apps which uses it) at _ALL_ costs to other stuff. Wrong. I call a good job giving a _preference_ to the desktop. I call rigid fairness impractical for the desktop, and a denial of reality. My sound programs (audacity, non-RT) and mplayer disaggree with you. :-) Not to mention some more mundane stuff like Gajim. (no stall with its slow PyGTK UI on RSDL) (Hint: I'm using Xfce, not KDE) I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. A much better approach would be running IO in the context of the app, but using a common shared library. Also, Beryl works better with RSDL too. (blur doesn't disable itself sometimes - which is the result of a lag) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. P.S. For those folks who appear to think that I'm in love with mainline behavior and blissfully ignorant of it's shortcomings. http://lwn.net/Articles/176635/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
Mike Galbraith wrote: On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. -Mike maybe if it is possible to classify program behaviors that cause RSDL to do bad (relatively) or the mainline scheduler to jitter, we could try modifying the existing heuristics to get a better default scheduler. of course, it wouldn't be able to cater to all the workloads and would meet everybody's definition of optimal. but getting close to optimal in most cases should be a good enough goal for linux's default sched! i've been following this thread, and there's been many instances of 'RSDL is gr8' and 'RSDL regresses'. maybe RSDL isn't the answer. maybe the current mainline sched isn't either. but RSDL definitely has done *something* right. What i think is needed is 'why this works here' and 'how to get this behavior to work with some other possibly conflicting but important workloads'. (just my 2c :-) -jb -- I am professionally trained in computer science, which is to say (in all seriousness) that I am extremely poorly educated. -- Joseph Weizenbaum - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sun, 2007-03-18 at 13:50 +0530, jimmy bahuleyan wrote: maybe if it is possible to classify program behaviors that cause RSDL to do bad (relatively) or the mainline scheduler to jitter, we could try modifying the existing heuristics to get a better default scheduler. of course, it wouldn't be able to cater to all the workloads and would meet everybody's definition of optimal. but getting close to optimal in most cases should be a good enough goal for linux's default sched! i've been following this thread, and there's been many instances of 'RSDL is gr8' and 'RSDL regresses'. maybe RSDL isn't the answer. maybe the current mainline sched isn't either. but RSDL definitely has done *something* right. Agreed. What i think is needed is 'why this works here' and 'how to get this behavior to work with some other possibly conflicting but important workloads'. (just my 2c :-) IMHO, that's worth more than 2c. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sun, 2007-03-18 at 08:38 +0100, Mike Galbraith wrote: On Sun, 2007-03-18 at 08:22 +0100, Radoslaw Szkodzinski wrote: I'd recon KDE regresses because of kioslaves waiting on a pipe (communication with the app they're doing IO for) and then expiring. That's why splitting IO from an app isn't exactly smart. It should at least be ran in an another thread. Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On 3/18/07, Kasper Sandberg [EMAIL PROTECTED] wrote: not really, only X sucks. KDE works atleast as good with rsdl as vanilla. i dont know how originally said kde works worse, wasnt it just someone that thought? Couldn't agree more, been using RSDL+KDE for a week now, and as far as I'm concerned I will be sticking with this until it goes to mainline, or mainline exhibits better behaviour. The fact of the matter is I was always unsure why windows 'feels' so much better than linux. RSDL makes it feel like windows, all the time, no matter what's going on. I'm really miffed when anyone talks about regressions, because I have scenarios that will completely lock up linux for 10s or so on my athlon 4200x2, due to [really] poorly designed apps that I need to run. RSDL seems to work right though it; it works faster, mouse feels better, browser scrolls smoothly, can't make the sound skip, video is fluid, opening a term is instant, boot up is faster, all which are a step up from mainline. That's the facts. IME I have seen nothing but good with RSDL. -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On 3/18/07, Mike Galbraith [EMAIL PROTECTED] wrote: Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. Blah. Nothing's perfect. Especially not computer programs. Still, it's not a smart decision on KDE's part. It will break a lot of scheduling decisions, esp. you can't use IO priorities. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
Op Sunday 18 March 2007, schreef Radoslaw Szkodzinski: On 3/18/07, Mike Galbraith [EMAIL PROTECTED] wrote: Hm. Sounds rather a lot like the... X sucks, fix X and RSDL will rock your world. RSDL is perfect. ...that I've been getting. Blah. Nothing's perfect. Especially not computer programs. Still, it's not a smart decision on KDE's part. It will break a lot of scheduling decisions, esp. you can't use IO priorities. Well, if somebody could explain what they should do instead of what they're doing, I can contact them - the libraries for KDE 4 aren't in feature freeze yet (they will be, though) so they can solve the problem(s). The KIO infrastructure is ATM under a redesign, so please, if you know what they should do/are doing wrong, speak up! grtz Jos pgpurtRxp14WS.pgp Description: PGP signature
Re: [ck] Re: RSDL v0.31
On Sat, 2007-03-17 at 19:23 +0100, Kacper Wysocki wrote: > And for Mark and others who are as confused as I was, this is the > thread that Mike meant to reference: > http://thread.gmane.org/gmane.linux.kernel/503455/focus=6614 Nope, with all the back and forth (and noise), I lost track of which thread was which. Thanks. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On 3/17/07, Mike Galbraith <[EMAIL PROTECTED]> wrote: On Sat, 2007-03-17 at 13:03 -0400, Gene Heskett wrote: > On Saturday 17 March 2007, Mike Galbraith wrote: > [...] > >Xorg is using 50% cpu because I'm asking it to. > > What advantage is that giving you? It's a test scenario. Read the thread please, I really don't want to repeat myself endlessly. I've been following "this thread" since Con's .31 announcement - and the only reference to your test scenario that you've given is that you're still "having trouble with x/gforce vs two niced encoders", that you've added "some targeted unfairness", that Con's new scheduler is "an utter failure" and something about beating it to a bloody pulp. You haven't detailed what your test actually is or what it's trying to acheive, nor provided anyone else with the means to reproduce it or understand any of the behaviour you're seeing. Now if you've done that in any other thread, consider referencing it instead of worrying about "repeating yourself endlessly". Otherwise, you're making it pretty clear that you're just trying to be difficult, rather than being heard. Remember, this thread is not only cross-posted, but also exists in a high-volume mailing list where things aren't as easy to track as in one's own head. And for Mark and others who are as confused as I was, this is the thread that Mike meant to reference: http://thread.gmane.org/gmane.linux.kernel/503455/focus=6614 Cheers, -Kacper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 2007-03-17 at 07:54 -0700, Mark Glines wrote: > On Sat, 17 Mar 2007 15:33:41 +0100 > Mike Galbraith <[EMAIL PROTECTED]> wrote: > > > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P > > > > COMMAND 6599 root 26 0 174m 30m 8028 R 51 3.1 > > > > 7:08.70 0 Xorg > > > > > > > This is a snippet from a hacked up by me version of RSDL.30, not > > stock. > > Oops. Thanks, sorry about my confusion. What does it look like without > your patches? (I'm not sure if you've already sent this... I can't > find any in the list archives.) If you go to the beginning of the thread, I described the test load. (I don't want to rehash... 'nuff turbulence) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 17 Mar 2007 15:33:41 +0100 Mike Galbraith <[EMAIL PROTECTED]> wrote: > > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P > > > COMMAND 6599 root 26 0 174m 30m 8028 R 51 3.1 > > > 7:08.70 0 Xorg > > > > This is a snippet from a hacked up by me version of RSDL.30, not > stock. Oops. Thanks, sorry about my confusion. What does it look like without your patches? (I'm not sure if you've already sent this... I can't find any in the list archives.) Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 17 Mar 2007 09:46:27 +0100 Mike Galbraith <[EMAIL PROTECTED]> wrote: > On Fri, 2007-03-16 at 23:44 -0800, David Lang wrote: > > > why isn't niceing X to -10 an acceptable option? > > Xorg's priority is only part of the problem. Every client that needs > a substantial quantity of cpu while a hog is running will also need > to be negative nice, no? I don't suppose you can be a bit more specific, and define how much CPU constitutes a "substantial quantity"? It looks to me like X already got about half of a CPU. > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND > 6599 root 26 0 174m 30m 8028 R 51 3.1 7:08.70 0 Xorg I'm hoping that actually quantifying this issue will result in a better understanding of the issue... Thanks, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 2007-03-17 at 07:09 -0700, Mark Glines wrote: > I don't suppose you can be a bit more specific, and define how much CPU > constitutes a "substantial quantity"? It looks to me like X already got > about half of a CPU. > > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND > > 6599 root 26 0 174m 30m 8028 R 51 3.1 7:08.70 0 Xorg > This is a snippet from a hacked up by me version of RSDL.30, not stock. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Saturday 17 March 2007 07:07, jos poortvliet wrote: > Op Saturday 17 March 2007, schreef Ingo Molnar: > > so it is not at all clear to me that RSDL is indeed an improvement, if > > it does not have comparable auto-nice properties. > > Wasn't the point of RSDL to get rid of the auto-nice, because it caused > starvation, unpredictable behaviour and other problems? > > Anyway, I think it's a good thing we keep having a look at mike's problem, > but > it's not clear to me how far he got in solving it. Does the latest patch > solve the interactivity problem, providing X is niced -10 (or something)??? > > If it does, I think that's the solution - at least until the X ppl fix X > itself. Distributions can just go back renicing X (they did that before, > after all), and the biggest problem is fixed. Then all other users can have > the improvements RSDL offers, the developers can rejoice over the simpler and > cleaner design and code, and everybody is happy. > > If it doesn't solve the problem, more work is in order. I think ignoring a > clear regression to mainline, no matter how rare, isn't smart. It might > indicate an underlying problem, and even if it doesn't - you don't want ppl > complaining the new kernel isn't interactive anymore or something... Ingo, The other point to make here is that you only need to nice X if you are heavily overloading the box. Here X is NOT niced and RSDL 0.30 is giving me better performance. Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On 3/17/07, Mike Galbraith <[EMAIL PROTECTED]> wrote: On Sat, 2007-03-17 at 20:48 +1100, Con Kolivas wrote: > The most frustrating part of a discussion of this nature on lkml is that > earlier information in a thread seems to be long forgotten after a few days > and all that is left is the one reporter having a problem. One? I'm not the only person who reported regression. Con is over-simplifying here -- he is saying the number of regression-reporters is dwarfed by the number of positive responses. One regression in particular, though, is rather persistent, and we are unsure of how to solve it in a way that fits the ideals of RSDL. There has been one class of problems that have been reported against RSDL (problems with X or some X+GL-based app in the context of CPU-intensive programs) that has yet to be "resolved", AFAICS. The possible solutions being brought up (e.g. auto-nice in the kernel) go against the fundamental reasons and logic behind RSDL. The latest (RSDL 0.31) is supposed to help with relatively-niced latency-sensitive programs (which were reported earlier) and there is some progress, although I believe maybe one or two people are still reporting issues here. We are making progress in this circumstance that Con feels is acceptable. (Again, the remaining potential solutions being proposed so far go against RSDL's fundamental ideals. If we actually have to use these solutions, then basically we're just doing the vanilla scheduler all over again -- defeating the purpose of RSDL in the first place.) akpm, IIRC, reported an issue on PPC with an early version of RSDL (presumably a broken one) when he tried to build the first public release with -mm; we have yet to hear negative feedback from him (on the -ck list at least) saying this problem persisted with future releases. I think the idea is that Con has seen much greater positive response (particularly with earlier releases, i.e. a week ago), and a lack of thorough, viable solutions (particularly ones that either come with a patch or fit in with the current ideal of RSDL) for the complaints being brought up that he is feeling frustrated. (Con's neck problem is preventing him from spending too much time coding solutions himself, and I feel the discussion that is going on here is starting to become counterproductive in consideration of that.) I've also seen no one mention the possibility of slowdowns on RSDL being a placebo effect type thing. That said, this "regression" on the "broken code" in X is probably an issue that we do need to at least watch for. The "average" desktop user, I would assume, is probably running X. (The question is, whether they would be running "too many" CPU-intensive programs at the same time. If so, then I would imagine they're not "average" any more, but I could some misunderstandings about this.) I think many of us have certain ideals about the performance of graphical user interfaces (we'd like X to be super-responsive, all the time, regardless of what processes are running, with as little impact on the CPU-intensive processes as possible) although I don't think we're at the level where we can get there yet. The question is (for the time being) how we're willing to assign things in this circumstance. And, as far as I can see, no one appears to have even attempted to answer Con's question of how much CPU a nice 5 process should get relative to nice 0, etc., apart from maybe Con himself. Personally, I think a nice 5 process should get 50% of the CPU time of a nice 0, but I'm not sure how that would scale to nice 19 or nice -19. -- -- Michael Chang ~Just the crazy copy cat~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
Op Saturday 17 March 2007, schreef Ingo Molnar: > so it is not at all clear to me that RSDL is indeed an improvement, if > it does not have comparable auto-nice properties. Wasn't the point of RSDL to get rid of the auto-nice, because it caused starvation, unpredictable behaviour and other problems? Anyway, I think it's a good thing we keep having a look at mike's problem, but it's not clear to me how far he got in solving it. Does the latest patch solve the interactivity problem, providing X is niced -10 (or something)??? If it does, I think that's the solution - at least until the X ppl fix X itself. Distributions can just go back renicing X (they did that before, after all), and the biggest problem is fixed. Then all other users can have the improvements RSDL offers, the developers can rejoice over the simpler and cleaner design and code, and everybody is happy. If it doesn't solve the problem, more work is in order. I think ignoring a clear regression to mainline, no matter how rare, isn't smart. It might indicate an underlying problem, and even if it doesn't - you don't want ppl complaining the new kernel isn't interactive anymore or something... /Jos -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. pgp2esWSV0tI7.pgp Description: PGP signature
Re: [ck] Re: RSDL v0.31
Op Saturday 17 March 2007, schreef Ingo Molnar: so it is not at all clear to me that RSDL is indeed an improvement, if it does not have comparable auto-nice properties. Wasn't the point of RSDL to get rid of the auto-nice, because it caused starvation, unpredictable behaviour and other problems? Anyway, I think it's a good thing we keep having a look at mike's problem, but it's not clear to me how far he got in solving it. Does the latest patch solve the interactivity problem, providing X is niced -10 (or something)??? If it does, I think that's the solution - at least until the X ppl fix X itself. Distributions can just go back renicing X (they did that before, after all), and the biggest problem is fixed. Then all other users can have the improvements RSDL offers, the developers can rejoice over the simpler and cleaner design and code, and everybody is happy. If it doesn't solve the problem, more work is in order. I think ignoring a clear regression to mainline, no matter how rare, isn't smart. It might indicate an underlying problem, and even if it doesn't - you don't want ppl complaining the new kernel isn't interactive anymore or something... /Jos -- Disclaimer: Alles wat ik doe denk en zeg is gebaseerd op het wereldbeeld wat ik nu heb. Ik ben niet verantwoordelijk voor wijzigingen van de wereld, of het beeld wat ik daarvan heb, noch voor de daaruit voortvloeiende gedragingen van mezelf. Alles wat ik zeg is aardig bedoeld, tenzij expliciet vermeld. pgp2esWSV0tI7.pgp Description: PGP signature
Re: [ck] Re: RSDL v0.31
On 3/17/07, Mike Galbraith [EMAIL PROTECTED] wrote: On Sat, 2007-03-17 at 20:48 +1100, Con Kolivas wrote: The most frustrating part of a discussion of this nature on lkml is that earlier information in a thread seems to be long forgotten after a few days and all that is left is the one reporter having a problem. One? I'm not the only person who reported regression. Con is over-simplifying here -- he is saying the number of regression-reporters is dwarfed by the number of positive responses. One regression in particular, though, is rather persistent, and we are unsure of how to solve it in a way that fits the ideals of RSDL. There has been one class of problems that have been reported against RSDL (problems with X or some X+GL-based app in the context of CPU-intensive programs) that has yet to be resolved, AFAICS. The possible solutions being brought up (e.g. auto-nice in the kernel) go against the fundamental reasons and logic behind RSDL. The latest (RSDL 0.31) is supposed to help with relatively-niced latency-sensitive programs (which were reported earlier) and there is some progress, although I believe maybe one or two people are still reporting issues here. We are making progress in this circumstance that Con feels is acceptable. (Again, the remaining potential solutions being proposed so far go against RSDL's fundamental ideals. If we actually have to use these solutions, then basically we're just doing the vanilla scheduler all over again -- defeating the purpose of RSDL in the first place.) akpm, IIRC, reported an issue on PPC with an early version of RSDL (presumably a broken one) when he tried to build the first public release with -mm; we have yet to hear negative feedback from him (on the -ck list at least) saying this problem persisted with future releases. I think the idea is that Con has seen much greater positive response (particularly with earlier releases, i.e. a week ago), and a lack of thorough, viable solutions (particularly ones that either come with a patch or fit in with the current ideal of RSDL) for the complaints being brought up that he is feeling frustrated. (Con's neck problem is preventing him from spending too much time coding solutions himself, and I feel the discussion that is going on here is starting to become counterproductive in consideration of that.) I've also seen no one mention the possibility of slowdowns on RSDL being a placebo effect type thing. That said, this regression on the broken code in X is probably an issue that we do need to at least watch for. The average desktop user, I would assume, is probably running X. (The question is, whether they would be running too many CPU-intensive programs at the same time. If so, then I would imagine they're not average any more, but I could some misunderstandings about this.) I think many of us have certain ideals about the performance of graphical user interfaces (we'd like X to be super-responsive, all the time, regardless of what processes are running, with as little impact on the CPU-intensive processes as possible) although I don't think we're at the level where we can get there yet. The question is (for the time being) how we're willing to assign things in this circumstance. And, as far as I can see, no one appears to have even attempted to answer Con's question of how much CPU a nice 5 process should get relative to nice 0, etc., apart from maybe Con himself. Personally, I think a nice 5 process should get 50% of the CPU time of a nice 0, but I'm not sure how that would scale to nice 19 or nice -19. -- -- Michael Chang ~Just the crazy copy cat~ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Saturday 17 March 2007 07:07, jos poortvliet wrote: Op Saturday 17 March 2007, schreef Ingo Molnar: so it is not at all clear to me that RSDL is indeed an improvement, if it does not have comparable auto-nice properties. Wasn't the point of RSDL to get rid of the auto-nice, because it caused starvation, unpredictable behaviour and other problems? Anyway, I think it's a good thing we keep having a look at mike's problem, but it's not clear to me how far he got in solving it. Does the latest patch solve the interactivity problem, providing X is niced -10 (or something)??? If it does, I think that's the solution - at least until the X ppl fix X itself. Distributions can just go back renicing X (they did that before, after all), and the biggest problem is fixed. Then all other users can have the improvements RSDL offers, the developers can rejoice over the simpler and cleaner design and code, and everybody is happy. If it doesn't solve the problem, more work is in order. I think ignoring a clear regression to mainline, no matter how rare, isn't smart. It might indicate an underlying problem, and even if it doesn't - you don't want ppl complaining the new kernel isn't interactive anymore or something... Ingo, The other point to make here is that you only need to nice X if you are heavily overloading the box. Here X is NOT niced and RSDL 0.30 is giving me better performance. Ed Tomlinson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 2007-03-17 at 07:09 -0700, Mark Glines wrote: I don't suppose you can be a bit more specific, and define how much CPU constitutes a substantial quantity? It looks to me like X already got about half of a CPU. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 6599 root 26 0 174m 30m 8028 R 51 3.1 7:08.70 0 Xorg This is a snippet from a hacked up by me version of RSDL.30, not stock. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 17 Mar 2007 09:46:27 +0100 Mike Galbraith [EMAIL PROTECTED] wrote: On Fri, 2007-03-16 at 23:44 -0800, David Lang wrote: why isn't niceing X to -10 an acceptable option? Xorg's priority is only part of the problem. Every client that needs a substantial quantity of cpu while a hog is running will also need to be negative nice, no? I don't suppose you can be a bit more specific, and define how much CPU constitutes a substantial quantity? It looks to me like X already got about half of a CPU. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 6599 root 26 0 174m 30m 8028 R 51 3.1 7:08.70 0 Xorg I'm hoping that actually quantifying this issue will result in a better understanding of the issue... Thanks, Mark - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 17 Mar 2007 15:33:41 +0100 Mike Galbraith [EMAIL PROTECTED] wrote: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 6599 root 26 0 174m 30m 8028 R 51 3.1 7:08.70 0 Xorg This is a snippet from a hacked up by me version of RSDL.30, not stock. Oops. Thanks, sorry about my confusion. What does it look like without your patches? (I'm not sure if you've already sent this... I can't find any in the list archives.) Mark - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 2007-03-17 at 07:54 -0700, Mark Glines wrote: On Sat, 17 Mar 2007 15:33:41 +0100 Mike Galbraith [EMAIL PROTECTED] wrote: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 6599 root 26 0 174m 30m 8028 R 51 3.1 7:08.70 0 Xorg This is a snippet from a hacked up by me version of RSDL.30, not stock. Oops. Thanks, sorry about my confusion. What does it look like without your patches? (I'm not sure if you've already sent this... I can't find any in the list archives.) If you go to the beginning of the thread, I described the test load. (I don't want to rehash... 'nuff turbulence) -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On 3/17/07, Mike Galbraith [EMAIL PROTECTED] wrote: On Sat, 2007-03-17 at 13:03 -0400, Gene Heskett wrote: On Saturday 17 March 2007, Mike Galbraith wrote: [...] Xorg is using 50% cpu because I'm asking it to. What advantage is that giving you? It's a test scenario. Read the thread please, I really don't want to repeat myself endlessly. I've been following this thread since Con's .31 announcement - and the only reference to your test scenario that you've given is that you're still having trouble with x/gforce vs two niced encoders, that you've added some targeted unfairness, that Con's new scheduler is an utter failure and something about beating it to a bloody pulp. You haven't detailed what your test actually is or what it's trying to acheive, nor provided anyone else with the means to reproduce it or understand any of the behaviour you're seeing. Now if you've done that in any other thread, consider referencing it instead of worrying about repeating yourself endlessly. Otherwise, you're making it pretty clear that you're just trying to be difficult, rather than being heard. Remember, this thread is not only cross-posted, but also exists in a high-volume mailing list where things aren't as easy to track as in one's own head. And for Mark and others who are as confused as I was, this is the thread that Mike meant to reference: http://thread.gmane.org/gmane.linux.kernel/503455/focus=6614 Cheers, -Kacper - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
On Sat, 2007-03-17 at 19:23 +0100, Kacper Wysocki wrote: And for Mark and others who are as confused as I was, this is the thread that Mike meant to reference: http://thread.gmane.org/gmane.linux.kernel/503455/focus=6614 Nope, with all the back and forth (and noise), I lost track of which thread was which. Thanks. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: RSDL v0.31
Freitag, 16. März 2007 wrote Mike Galbraith: > On Sat, 2007-03-17 at 08:13 +1100, Con Kolivas wrote: > > On Saturday 17 March 2007 02:34, Mike Galbraith wrote: > > > On Sat, 2007-03-17 at 00:40 +1100, Con Kolivas wrote: > > > > Here are full patches for rsdl 0.31 for various base kernels. A full > > > > announce with a fresh -mm series will follow... > > > > > > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.20.3-rsdl-0.31.p > > > >atch > > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-sched-rsd > > > >l-0. 31.patch > > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl- > > > >0.31 .patch > > > > > > It still has trouble with the x/gforce vs two niced encoders scenario. > > > The previously reported choppiness is still present. > > > > > > I suspect that x/gforce landing in the expired array is the trouble, > > > and that this will never be smooth without some kind of exemption. I > > > added some targeted unfairness to .30, and it didn't help much at all. > > > > > > Priorities going all the way to 1 were a surprise. > > > > It wasn't going to change that case without renicing X. > > Con. You are trying to wedge a fair scheduler into an environment where > totally fair simply can not possibly function. > > If this is your final answer to the problem space, I am done testing, > and as far as _I_ am concerned, your scheduler is an utter failure. > I can not let this comment stay like that. I have an AMD X2 4400+ Dual Core running Gentoo and now kernel 2.6.21-rc3 with RSDL 0.30 (HZ=300). Up till now whenever I wanted to watch a movie i had to stop compiling with more than one task for the movie to run without skips. When playing games i have to renice the game (-15-) or else it would get 'choppy'. With the new RSDL i compile packages with -j3 (reniced to 15), my wife lets up to 8 computations (scientific computations) running at the same time and the game and a movie still run without any visible flaws. The only thing i saw till now was that the mouse cursor was a little less responsive and scrolling in firefox took a little longer. But amarok for music, the movie in mplayer, the 3d game, everything went smooth though a load of > 11. This all without even renicing anything but the compiles. With mainline kernel already watching a movie with this load was impossible. I used the staircase scheduler before RSDL but even with staircase such overload was not possible while watching a movie. Mike, maybe use higher nice levels for your encoders or just use one. Or maybe scheck your memory, i guess if the memory bandwidth is too low there's no scheduler which can foresee such thing and react accordingly. Since you have a HT system it's just one physical ALU, so everything has to be squeezed onto this one ALU, up to a certain degree it works, but not forever. And the lame encoders i suppose won't wait that very much and long for their data to get delivered from memory so they'll utilize the ALU quite a lot. Con, continue your scheduler development as it helps many cases which were not possible otherwise. I'm amazed of the ability of the scheduler to handle a 5 times overloaded system without too much hazzle. Great work Con. Dirk. PS: Con, don't stress your neck too much, your health is the only thing you have to keep for live. pgpoF3c77vSOb.pgp Description: PGP signature
Re: [ck] Re: RSDL v0.31
Freitag, 16. März 2007 wrote Mike Galbraith: On Sat, 2007-03-17 at 08:13 +1100, Con Kolivas wrote: On Saturday 17 March 2007 02:34, Mike Galbraith wrote: On Sat, 2007-03-17 at 00:40 +1100, Con Kolivas wrote: Here are full patches for rsdl 0.31 for various base kernels. A full announce with a fresh -mm series will follow... http://ck.kolivas.org/patches/staircase-deadline/2.6.20.3-rsdl-0.31.p atch http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-sched-rsd l-0. 31.patch http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl- 0.31 .patch It still has trouble with the x/gforce vs two niced encoders scenario. The previously reported choppiness is still present. I suspect that x/gforce landing in the expired array is the trouble, and that this will never be smooth without some kind of exemption. I added some targeted unfairness to .30, and it didn't help much at all. Priorities going all the way to 1 were a surprise. It wasn't going to change that case without renicing X. Con. You are trying to wedge a fair scheduler into an environment where totally fair simply can not possibly function. If this is your final answer to the problem space, I am done testing, and as far as _I_ am concerned, your scheduler is an utter failure. I can not let this comment stay like that. I have an AMD X2 4400+ Dual Core running Gentoo and now kernel 2.6.21-rc3 with RSDL 0.30 (HZ=300). Up till now whenever I wanted to watch a movie i had to stop compiling with more than one task for the movie to run without skips. When playing games i have to renice the game (-15-) or else it would get 'choppy'. With the new RSDL i compile packages with -j3 (reniced to 15), my wife lets up to 8 computations (scientific computations) running at the same time and the game and a movie still run without any visible flaws. The only thing i saw till now was that the mouse cursor was a little less responsive and scrolling in firefox took a little longer. But amarok for music, the movie in mplayer, the 3d game, everything went smooth though a load of 11. This all without even renicing anything but the compiles. With mainline kernel already watching a movie with this load was impossible. I used the staircase scheduler before RSDL but even with staircase such overload was not possible while watching a movie. Mike, maybe use higher nice levels for your encoders or just use one. Or maybe scheck your memory, i guess if the memory bandwidth is too low there's no scheduler which can foresee such thing and react accordingly. Since you have a HT system it's just one physical ALU, so everything has to be squeezed onto this one ALU, up to a certain degree it works, but not forever. And the lame encoders i suppose won't wait that very much and long for their data to get delivered from memory so they'll utilize the ALU quite a lot. Con, continue your scheduler development as it helps many cases which were not possible otherwise. I'm amazed of the ability of the scheduler to handle a 5 times overloaded system without too much hazzle. Great work Con. Dirk. PS: Con, don't stress your neck too much, your health is the only thing you have to keep for live. pgpoF3c77vSOb.pgp Description: PGP signature
