Buried deep in another mail thread was the latest implementation of my O1int
patch so I've brought it to the surface to make it clear this one is
significantly different from past iterations.
Summary:
Decreases audio skipping with loads.
Smooths out X performance with load.
I've also made it available here:
http://kernel.kolivas.org/2.5
along with a patch called granularity that is a modified version of Ingo's
timeslice_granularity patch. It is no longer necessary and may slightly
decrease throughput in non-desktop settings but put on top of my O1int patch
makes X even smoother.
Con
On Tue, 1 Jul 2003, Con Kolivas wrote:
> Buried deep in another mail thread was the latest implementation of my O1int
> patch so I've brought it to the surface to make it clear this one is
> significantly different from past iterations.
>
> Summary:
> Decreases audio skipping with loads.
> Smooths out X performance with load.
I tried this with normal developer box type load on a slow box ie;
2x 400MHz 512MB source/build fs' on UW2 SCSI
kernel: 2.5.72-mm3
2x make -j2 bzImage
bk pull (linux-2.5 repo)
cvs import of 2.5 tree
navigating bk revtool (this normally causes pauses)
read disk benchmark just to thrash IDE about a bit ;)
Still a few MP3 pauses (due to bk revtool mainly) but mouse/keyboard
response was good, there is however a vast improvement over 2.5.73
stock (2-5s pauses with no keyboard/mouse response) for my particular
workload.
zwane@montezuma ~ {0:0} uptime
14:18:06 up 54 min, 25 users, load average: 7.33, 6.58, 5.59
zwane@montezuma ~ {0:0} vmstat 1
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
3 3 1 27444 3628 4012 108068 4 11 5837 1680 841 994 58 22 20
1 5 0 27428 4920 8184 107924 8 0 11292 948 1551 3081 49 51 0
3 3 1 27432 3832 7764 107664 0 8 13084 1440 1503 2192 52 45 3
1 5 0 27432 14552 20992 83772 332 0 16320 844 1632 2721 56 44 0
0 6 0 24500 15568 31548 91088 224 0 17160 0 1552 2423 67 33 0
2 4 1 24504 2916 33428 96788 32 0 21912 580 1703 2969 62 38 0
4 2 2 24508 3284 25688 98812 0 4 23248 2164 1575 2507 74 26 0
2 4 1 24512 2780 18984 103752 0 8 22412 796 1606 2693 76 24 0
6 2 0 24516 4012 13324 107712 0 4 20224 1604 1738 2916 69 31 0
6 1 1 24528 2196 14836 108172 0 8 20188 2472 2260 4051 58 42 0
--
function.linuxpower.ca
On Mon, 2003-06-30 at 16:29, Con Kolivas wrote:
> Buried deep in another mail thread was the latest implementation of my O1int
> patch so I've brought it to the surface to make it clear this one is
> significantly different from past iterations.
>
> Summary:
> Decreases audio skipping with loads.
> Smooths out X performance with load.
>
> I've also made it available here:
> http://kernel.kolivas.org/2.5
>
> along with a patch called granularity that is a modified version of Ingo's
> timeslice_granularity patch. It is no longer necessary and may slightly
> decrease throughput in non-desktop settings but put on top of my O1int patch
> makes X even smoother.
Damn! XMMS audio skips are back... To reproduce them, I start up my KDE
session, launch Konqueror, launch XMMS and make it play sound. Then, I
drag the Konqueror window like crazy over my desktop and XMMS skips,
altough not too much.
The previous version of this patch is the one that worked best for me.
On Tue, 1 Jul 2003 07:21, Felipe Alfaro Solana wrote:
> On Mon, 2003-06-30 at 16:29, Con Kolivas wrote:
> > Buried deep in another mail thread was the latest implementation of my
> > O1int patch so I've brought it to the surface to make it clear this one
> > is significantly different from past iterations.
> >
> > Summary:
> > Decreases audio skipping with loads.
> > Smooths out X performance with load.
> >
> > I've also made it available here:
> > http://kernel.kolivas.org/2.5
> >
> > along with a patch called granularity that is a modified version of
> > Ingo's timeslice_granularity patch. It is no longer necessary and may
> > slightly decrease throughput in non-desktop settings but put on top of my
> > O1int patch makes X even smoother.
>
> Damn! XMMS audio skips are back... To reproduce them, I start up my KDE
> session, launch Konqueror, launch XMMS and make it play sound. Then, I
> drag the Konqueror window like crazy over my desktop and XMMS skips,
> altough not too much.
>
> The previous version of this patch is the one that worked best for me.
A little bit more of this.. a little bit less of that... Use 100 or 1000Hz for
this one? And did you notice any change in X?
Con
Hello,
I'm running this patch for a couple of hours and it is worse than the
plain 2.5.73-bk7. It doesn't hang exactly (and I didn't listen to any
music, yet) but during normal work (switching x-screens, scrolling in
browser, pressing keys, etc.) the systems hangs non-deterministically
for maybe half a second or so. For example, when I typed this sentence I
noticed that pressing the backspace key didn't trigger anything for a
while and then it continued with the sentence (correctly, tho).
I cannot reproduce it and the machine is doing virtually nothing. Please
tell me if you need more information.
On Tue, Jul 01, 2003 at 12:29:19AM +1000, Con Kolivas wrote:
> Buried deep in another mail thread was the latest implementation of my
> O1int
> patch so I've brought it to the surface to make it clear this one is
> significantly different from past iterations.
>
> Summary:
> Decreases audio skipping with loads.
> Smooths out X performance with load.
--
Regards,
Wiktor Wodecki
On Tue, 1 Jul 2003 04:27, Zwane Mwaikambo wrote:
> On Tue, 1 Jul 2003, Con Kolivas wrote:
> > Buried deep in another mail thread was the latest implementation of my
> > O1int patch so I've brought it to the surface to make it clear this one
> > is significantly different from past iterations.
> >
> > Summary:
> > Decreases audio skipping with loads.
> > Smooths out X performance with load.
>
> I tried this with normal developer box type load on a slow box ie;
>
> 2x 400MHz 512MB source/build fs' on UW2 SCSI
> kernel: 2.5.72-mm3
>
> 2x make -j2 bzImage
> bk pull (linux-2.5 repo)
> cvs import of 2.5 tree
> navigating bk revtool (this normally causes pauses)
> read disk benchmark just to thrash IDE about a bit ;)
>
> Still a few MP3 pauses (due to bk revtool mainly) but mouse/keyboard
> response was good, there is however a vast improvement over 2.5.73
> stock (2-5s pauses with no keyboard/mouse response) for my particular
> workload.
Thanks for testing and working with me.
Please if others are testing and still having problems note this work is _not_
complete yet, but I do need to assess every incremental change to make sure
it addresses the issue I am trying to fix at each step.
For what it's worth there are still at least 3 things I need to
implement/change in this patch which induce problems still, so tell me of
your experiences and I will try hard to accomodate.
Con
On Mon, 2003-06-30 at 23:54, Con Kolivas wrote:
> On Tue, 1 Jul 2003 07:21, Felipe Alfaro Solana wrote:
> > On Mon, 2003-06-30 at 16:29, Con Kolivas wrote:
> > > Buried deep in another mail thread was the latest implementation of my
> > > O1int patch so I've brought it to the surface to make it clear this one
> > > is significantly different from past iterations.
> > >
> > > Summary:
> > > Decreases audio skipping with loads.
> > > Smooths out X performance with load.
> > >
> > > I've also made it available here:
> > > http://kernel.kolivas.org/2.5
> > >
> > > along with a patch called granularity that is a modified version of
> > > Ingo's timeslice_granularity patch. It is no longer necessary and may
> > > slightly decrease throughput in non-desktop settings but put on top of my
> > > O1int patch makes X even smoother.
> >
> > Damn! XMMS audio skips are back... To reproduce them, I start up my KDE
> > session, launch Konqueror, launch XMMS and make it play sound. Then, I
> > drag the Konqueror window like crazy over my desktop and XMMS skips,
> > altough not too much.
> >
> > The previous version of this patch is the one that worked best for me.
>
> A little bit more of this.. a little bit less of that... Use 100 or 1000Hz for
> this one? And did you notice any change in X?
I'm using 1000HZ. With respect to X, I haven't noticed any major
difference. Should I? I haven't tested it under very heavy loads, but
under normal workloads, it behaves a little better than its predecesors.
On Tue, 1 Jul 2003 18:59, Felipe Alfaro Solana wrote:
> On Mon, 2003-06-30 at 23:54, Con Kolivas wrote:
> > On Tue, 1 Jul 2003 07:21, Felipe Alfaro Solana wrote:
> > > On Mon, 2003-06-30 at 16:29, Con Kolivas wrote:
> > > > Buried deep in another mail thread was the latest implementation of
> > > > my O1int patch so I've brought it to the surface to make it clear
> > > > this one is significantly different from past iterations.
> > > >
> > > > Summary:
> > > > Decreases audio skipping with loads.
> > > > Smooths out X performance with load.
> > > >
> > > > I've also made it available here:
> > > > http://kernel.kolivas.org/2.5
> > > >
> > > > along with a patch called granularity that is a modified version of
> > > > Ingo's timeslice_granularity patch. It is no longer necessary and may
> > > > slightly decrease throughput in non-desktop settings but put on top
> > > > of my O1int patch makes X even smoother.
> > >
> > > Damn! XMMS audio skips are back... To reproduce them, I start up my KDE
> > > session, launch Konqueror, launch XMMS and make it play sound. Then, I
> > > drag the Konqueror window like crazy over my desktop and XMMS skips,
> > > altough not too much.
> > >
> > > The previous version of this patch is the one that worked best for me.
> >
> > A little bit more of this.. a little bit less of that... Use 100 or
> > 1000Hz for this one? And did you notice any change in X?
>
> I'm using 1000HZ. With respect to X, I haven't noticed any major
> difference. Should I? I haven't tested it under very heavy loads, but
> under normal workloads, it behaves a little better than its predecesors.
I'd say it would depend on the graphic card. On a sis630 even with a p3 1133
it is embarassingly jerky under even the slightest of loads without my patch.
However, it is as good now without the granularity patch as earlier with the
granularity.
Con
On Tue, 2003-07-01 at 11:31, Con Kolivas wrote:
> On Tue, 1 Jul 2003 18:59, Felipe Alfaro Solana wrote:
> > I'm using 1000HZ. With respect to X, I haven't noticed any major
> > difference. Should I? I haven't tested it under very heavy loads, but
> > under normal workloads, it behaves a little better than its predecesors.
>
> I'd say it would depend on the graphic card. On a sis630 even with a p3 1133
> it is embarassingly jerky under even the slightest of loads without my patch.
> However, it is as good now without the granularity patch as earlier with the
> granularity.
When I say "X feels jerky", I mean that I can notice the scheduler is
not giving the X server enough CPU cycles (I mean, a continuous,
smaller, but more frequent CPU timeslice) to perform window movement and
redrawing fast enough to get ~25fps. Also, I don't think it's related to
the video card. The combo patch I did with Mike's + Ingo's enhacements
works beautifully for me.
>On Tue, 2003-07-01 at 11:31, Con Kolivas wrote:
>> On Tue, 1 Jul 2003 18:59, Felipe Alfaro Solana wrote:
>> > I'm using 1000HZ. With respect to X, I haven't noticed any major
>> > difference. Should I? I haven't tested it under very heavy loads, but
>> > under normal workloads, it behaves a little better than its predecesors.
>>
>> I'd say it would depend on the graphic card. On a sis630 even with a p3
>> 1133 it is embarassingly jerky under even the slightest of loads without
>> my patch. However, it is as good now without the granularity patch as
>> earlier with the granularity.
>
>When I say "X feels jerky", I mean that I can notice the scheduler is
>not giving the X server enough CPU cycles (I mean, a continuous,
>smaller, but more frequent CPU timeslice) to perform window movement and
>redrawing fast enough to get ~25fps. Also, I don't think it's related to
>the video card. The combo patch I did with Mike's + Ingo's enhacements
>works beautifully for me.
Actually just the bastardised Ingo patch will do that on it's own. However
that's never going to be incorporated.
Con
On Tue, 2003-07-01 at 14:04, Con Kolivas wrote:
> >When I say "X feels jerky", I mean that I can notice the scheduler is
> >not giving the X server enough CPU cycles (I mean, a continuous,
> >smaller, but more frequent CPU timeslice) to perform window movement and
> >redrawing fast enough to get ~25fps. Also, I don't think it's related to
> >the video card. The combo patch I did with Mike's + Ingo's enhacements
> >works beautifully for me.
>
> Actually just the bastardised Ingo patch will do that on it's own. However
> that's never going to be incorporated.
So, I guess we won't have the option to choose between different CPU
schedulers (desktop or server, for example), like we have in -mm kernels
with IO schedulers (deadline or anticipatory).
Seriously talking, I prefer to have the best performance in my server
boxes, but for my laptop, I prefer shorter timeslices, lower peformance
and better turnaround times and a wiser CPU scheduler. Just my two
cents.
It's sad to say but I feel the vanilla 2.5 CPU scheduler doesn't match
my end-user preferences :-(
On Tue, 1 Jul 2003 23:17, Felipe Alfaro Solana wrote:
> On Tue, 2003-07-01 at 14:04, Con Kolivas wrote:
> > >When I say "X feels jerky", I mean that I can notice the scheduler is
> > >not giving the X server enough CPU cycles (I mean, a continuous,
> > >smaller, but more frequent CPU timeslice) to perform window movement and
> > >redrawing fast enough to get ~25fps. Also, I don't think it's related to
> > >the video card. The combo patch I did with Mike's + Ingo's enhacements
> > >works beautifully for me.
> >
> > Actually just the bastardised Ingo patch will do that on it's own.
> > However that's never going to be incorporated.
>
> So, I guess we won't have the option to choose between different CPU
> schedulers (desktop or server, for example), like we have in -mm kernels
> with IO schedulers (deadline or anticipatory).
>
> Seriously talking, I prefer to have the best performance in my server
> boxes, but for my laptop, I prefer shorter timeslices, lower peformance
> and better turnaround times and a wiser CPU scheduler. Just my two
> cents.
>
> It's sad to say but I feel the vanilla 2.5 CPU scheduler doesn't match
> my end-user preferences :-(
There will always be alternate trees. Whether options like this make it into
mainline will be up to the maintainer of course, but given that we seem to
have a "swappiness" dial in mainline then I suspect we may have more dials in
2.6 than before.
Con
At 11:29 PM 7/1/2003 +1000, Con Kolivas wrote:
>On Tue, 1 Jul 2003 23:17, Felipe Alfaro Solana wrote:
> > On Tue, 2003-07-01 at 14:04, Con Kolivas wrote:
> > > >When I say "X feels jerky", I mean that I can notice the scheduler is
> > > >not giving the X server enough CPU cycles (I mean, a continuous,
> > > >smaller, but more frequent CPU timeslice) to perform window movement and
> > > >redrawing fast enough to get ~25fps. Also, I don't think it's related to
> > > >the video card. The combo patch I did with Mike's + Ingo's enhacements
> > > >works beautifully for me.
> > >
> > > Actually just the bastardised Ingo patch will do that on it's own.
> > > However that's never going to be incorporated.
> >
> > So, I guess we won't have the option to choose between different CPU
> > schedulers (desktop or server, for example), like we have in -mm kernels
> > with IO schedulers (deadline or anticipatory).
> >
> > Seriously talking, I prefer to have the best performance in my server
> > boxes, but for my laptop, I prefer shorter timeslices, lower peformance
> > and better turnaround times and a wiser CPU scheduler. Just my two
> > cents.
> >
> > It's sad to say but I feel the vanilla 2.5 CPU scheduler doesn't match
> > my end-user preferences :-(
>
>There will always be alternate trees. Whether options like this make it into
>mainline will be up to the maintainer of course, but given that we seem to
>have a "swappiness" dial in mainline then I suspect we may have more dials in
>2.6 than before.
I don't like knobs at all [1], but I have to ~agree with Felipe.
A prime candidate for a knob (rather switch) would be a slightly more sane
back-boost for desktop use. I'm playing with back-boost in my tree,
allowing a limited quantity, and strictly from user tasks... it helps the
desktop quite a bit. Another thing that's very important for the desktop
(and shell) is startup time for new tasks. I'm working on something there
too (works great when it's not busy breaking everything to
pieces;). Modulo me ever getting that darn thing working acceptably well,
another candidate is to either export CHILD_PENALTY as in scheduler knobs
patch, or just set it to ~75-~85 when back-boost is enabled, ie make one
desktop mode switch and hope like heck it doesn't cause more trouble than
it's worth.
-Mike
1. Dear LKML, why does performance suck? My .config and 10000 random knob
settings attached.