Re: Interbench real time benchmark results

[Con Kolivas]

On Wed, 20 Jul 2005 11:31 am, Jesper Juhl wrote:
> On 7/20/05, Daniel Walker <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-07-20 at 11:04 +1000, Con Kolivas wrote:
> > > On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote:
> > > > On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote:
> > > > >  - networking is another frequent source of latencies - it might
> > > > > make sense to add a workload doing lots of socket IO. (localhost
> > > > > might be enough, but not for everything)
> > > >
> > > > The Gnutella test?
> > >
> > > I've seen some massive latencies on mainline when throwing network
> > > loads from outside, but with my limited knowledge I haven't found a way
> > > to implement such a thing locally. I'll look at this gnutella test at
> > > some stage to see what it is and if I can adopt the load within
> > > interbench. Thanks for the suggestion.
> >
> > There isn't actually a test called "The Gnutella test" , but I think
> > Gnutella clients put lots of network load on a system (Lee was talking
> > about that not to long ago). I was thinking that type of load may have
> > been what Ingo was talking about.
>
> If you want to generate a lot of network related interrupts, wouldn't
> a much simpler way to do that be a simple
>
>   ping -f targetbox
>
> from a host connected to `targetbox' via a crosswired ethernet cable
> or a fast switch..?
>
> Also easy to modify the size of the ping packets if you want to.

Well that load works very well, but once again it isn't really something that 
can be done locally on one box running init 1.

Cheers,
Con
-
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: Interbench real time benchmark results

[Con Kolivas]

On Wed, 20 Jul 2005 10:23 am, Daniel Walker wrote:
> On Wed, 2005-07-20 at 00:32 +0200, Ingo Molnar wrote:
> >  - networking is another frequent source of latencies - it might make
> >sense to add a workload doing lots of socket IO. (localhost might be
> >enough, but not for everything)
>
> The Gnutella test?

I've seen some massive latencies on mainline when throwing network loads from 
outside, but with my limited knowledge I haven't found a way to implement 
such a thing locally. I'll look at this gnutella test at some stage to see 
what it is and if I can adopt the load within interbench. Thanks for the 
suggestion.

Cheers,
Con
-
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: [ANNOUNCE] Interbench v0.21

[Con Kolivas]

On Sat, 16 Jul 2005 06:41 pm, Lee Revell wrote:
> On Fri, 2005-07-15 at 14:01 +1000, Con Kolivas wrote:
> > Interbech is a an application is designed to benchmark interactivity in
> > Linux.
> >
> > Version 0.21 update
> >
> > http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2
>
> I would suggest using microseconds for both the RT and non RT tests.  It
> would allow easier comparison of results.  I have a pretty slow machine
> and the max result would only be ~44000 usecs.

I think the significance of usec values from the non-rt tests makes this an 
inappropriate thing to do. The variation in results will be greater than usec 
resolution.

> Also, if it's run with -r and sched_setscheduler fails, rather than
> saying "you must be root for SCHED_FIFO" the error message should
> encourage the user to try a 2.6.12+ kernel and add themselves to the
> "audio" or "realtime" group, and to file a feature request if their
> distro does not support the new realtime rlimit feature.
>
> We should encourage more applications to take advantage of, and distros
> to support, the non-root RT scheduling available in 2.6.12+.  I really
> think the kernel is good enough at this point that we could achieve
> OSX-like multimedia performance on the desktop if more apps like xmms,
> xine, and mplayer were to adopt a multithreaded model with the
> time-critical rendering threads running RT.  XMMS recently adopted such
> a model, but I don't think the audio thread runs SCHED_FIFO yet.  These
> benchmarks imply that it would be a massive improvement.

While I agree with you in principal on getting the rlimit feature working and 
supported, this benchmark is meant to be run in single user mode for most 
reproducible and valid results. However, clearly there will be people using 
it cautiously as a normal user first. I originally did not include the 
information that you need to be root in v.20 and said in the documentation 
"need rt privileges" but within about 5 minutes of posting it I had someone 
not understanding what "unable to get SCHED_FIFO" meant. I guess a more 
verbose message will be required explaining non-root RT as well.

Cheers,
Con
-
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: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Con Kolivas]

On Fri, 15 Jul 2005 09:25, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Lee Revell wrote:
> > On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> > > I have to say, this whole thread has been pretty damn worthless in
> > > general in my not-so-humble opinion.
> >
> > This thread has really gone OT, but to revisit the original issue for a
> > bit, are you still unwilling to consider leaving the default HZ at 1000
> > for 2.6.13?
>
> Yes. I see absolutely no point to it until I actually hear people who have
> actually tried some real load that doesn't work. Dammit, I want a real
> user who says that he can noticeable see his DVD stuttering, not some
> theory.

Disclaimer - This is not proof of a real world dvd stuttering, simply a 
benchmarked result. My code may be crap, but then the real apps out there may 
also be.

Results from interbench v0.21 
(http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2)

2.6.13-rc1 on a pentium4 3.06

HZ=1000:
--- Benchmarking Audio in the presence of loads ---
Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.012 +/- 0.001960.021 100100
Video  1.28 +/- 0.509   2.01 100100
X 0.289 +/- 0.578  2 100100
Burn  0.014 +/- 0.002  0.023 100100
Write 0.025 +/- 0.0349  0.49 100100
Read   0.02 +/- 0.003830.052 100100
Compile   0.023 +/- 0.007520.054 100100
Memload   0.222 +/- 0.892   9.04 100100

--- Benchmarking Video in the presence of loads ---
Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.012 +/- 0.001690.023 100100
X  2.55 +/- 2.3718.7 100   75.8
Burn   1.08 +/- 1.0616.7 100   88.2
Write 0.224 +/- 0.215   16.7 100   97.8
Read  0.019 +/- 0.003540.059 100100
Compile4.55 +/- 4.5317.6 100   57.5
Memload 1.3 +/- 1.3451.5 100 88


HZ=250:
--- Benchmarking Audio in the presence of loads ---
Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.011 +/- 0.001520.022 100100
Video 0.157 +/- 0.398   3.62 100100
X   1.3 +/- 1.824.01 100100
Burn  0.014 +/- 0.001420.026 100100
Write 0.022 +/- 0.0125 0.092 100100
Read  0.021 +/- 0.003660.048 100100
Compile0.03 +/- 0.0469 0.559 100100
Memload   0.144 +/- 0.681   8.05 100100

--- Benchmarking Video in the presence of loads ---
Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  5 +/- 4.9916.7 100 54
X  9.98 +/- 8.9420.7 100   31.2
Burn   16.6 +/- 16.616.7 100  0.167
Write  4.11 +/- 4.0816.7 100   60.8
Read   2.55 +/- 2.5316.7 100   73.8
Compile15.6 +/- 15.617.7 1003.5
Memload2.91 +/- 2.9245.4 100   72.5


Audio did show slightly larger max latencies but nothing that would be of 
significance.

On video, maximum latencies are only slightly larger at HZ 250, all the 
desired cpu was achieved, but the average latency and number of missed 
deadlines was significantly higher.

Cheers,
Con


pgp55H3zXUdbU.pgp
Description: PGP signature

[ANNOUNCE] Interbench v0.21

[Con Kolivas]

Interbech is a an application is designed to benchmark interactivity in Linux.

Version 0.21 update

http://ck.kolivas.org/apps/interbench/interbench-0.21.tar.bz2


Changes:

Changed the design to run the benchmarked and background loads as separate 
processes that spawn their own threads instead of everything running as a 
thread of the same process. This was suggested to me originally by Ingo 
Molnar who noticed significant slowdown due to conflict over ->mm->mmap_sem, 
invalidating the benchmark results when run in real time mode. This makes a 
large difference to the latencies measured under mem_load particularly when 
running real time benchmarks on a RT-PREEMPT kernel.

Accounting changes to max_latency to only measure the largest latency of a 
single scheduling frame - this makes max_latency much smaller (and probably 
more realistic). Often you may see max latency exactly one frame wide now 
(consistent with one dropped frame) such as 16.7ms on video.

Minor cleanups.

Cheers,
Con


pgpIMsbekm6kw.pgp
Description: PGP signature

Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark

[Con Kolivas]

On Thu, 14 Jul 2005 10:46, Con Kolivas wrote:
> On Thu, 14 Jul 2005 10:31, David Lang wrote:
> > On Thu, 14 Jul 2005, Con Kolivas wrote:
> > > On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
> > >> Con Kolivas wrote:
> > >>> On Tue, 12 Jul 2005 21:57, David Lang wrote:
> > >>>> for audio and video this would seem to be a fairly simple scaleing
> > >>>> factor (or just doing a fixed amount of work rather then a fixed
> > >>>> percentage of the CPU worth of work), however for X it is probably
> > >>>> much more complicated (is the X load really linearly random in how
> > >>>> much work it does, or is it weighted towards small amounts with
> > >>>> occasional large amounts hitting? I would guess that at least beyond
> > >>>> a certin point the liklyhood of that much work being needed would be
> > >>>> lower)
> > >>>
> > >>> Actually I don't disagree. What I mean by hardware changes is more
> > >>> along the lines of changing the hard disk type in the same setup.
> > >>> That's what I mean by careful with the benchmarking. Taking the
> > >>> results from an athlon XP and comparing it to an altix is silly for
> > >>> example.
> > >>
> > >> I'm going to cautiously disagree. If the CPU needed was scaled so it
> > >> represented a fixed number of cycles (operations, work units) then the
> > >> effect of faster CPU would be shown. And the total power of all
> > >> attached CPUs should be taken into account, using HT or SMP does have
> > >> an effect of feel.
> > >
> > > That is rather hard to do because each architecture's interpretation of
> > > fixed number of cycles is different and this doesn't represent their
> > > speed in the real world. The calculation when interbench is first run
> > > to see how many "loops per ms" took quite a bit of effort to find just
> > > how many loops each different cpu would do per ms and then find a way
> > > to make that not change through compiler optimised code. The "loops per
> > > ms" parameter did not end up being proportional to cpu Mhz except on
> > > the same cpu type.
> >
> > right, but the amount of cpu required to do a specific task will also
> > vary significantly between CPU families for the same task as well. as
> > long as the loops don't get optimized away by the compiler I think you
> > can setup some loops to do the same work on each CPU, even if they take
> > significantly different amounts of time (as an off-the-wall, obviously
> > untested example you could make your 'loop' be a calculation of Pi and
> > for the 'audio' test you compute the first 100 digits, for the video test
> > you compute the first 1000 digits, and for the X test you compute a
> > random number of digits between 10 and 1)
>
> Once again I don't disagree, and the current system of loops_per_ms does
> exactly that and can be simply used as a fixed number of loops already. My
> point was there'd be argument about what sort of "loop" or load should be
> used as each cpu type would do different "loops" faster and they won't
> necessarily represent video, audio or X in the real world. Currently the
> loop in interbench is simply:
>   for (i = 0 ; i < loops ; i++)
>asm volatile("" : : : "memory");
>
> and if noone argues i can use that for fixed workload.

What I mean is if you take the loops_per_ms from one machine and plug it in 
using the -l option on another you can do it now without any modification to 
the interbench code.

Cheers,
Con


pgpgytBJmEKy6.pgp
Description: PGP signature

Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark

[Con Kolivas]

On Thu, 14 Jul 2005 10:31, David Lang wrote:
> On Thu, 14 Jul 2005, Con Kolivas wrote:
> > On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
> >> Con Kolivas wrote:
> >>> On Tue, 12 Jul 2005 21:57, David Lang wrote:
> >>>> for audio and video this would seem to be a fairly simple scaleing
> >>>> factor (or just doing a fixed amount of work rather then a fixed
> >>>> percentage of the CPU worth of work), however for X it is probably
> >>>> much more complicated (is the X load really linearly random in how
> >>>> much work it does, or is it weighted towards small amounts with
> >>>> occasional large amounts hitting? I would guess that at least beyond a
> >>>> certin point the liklyhood of that much work being needed would be
> >>>> lower)
> >>>
> >>> Actually I don't disagree. What I mean by hardware changes is more
> >>> along the lines of changing the hard disk type in the same setup.
> >>> That's what I mean by careful with the benchmarking. Taking the results
> >>> from an athlon XP and comparing it to an altix is silly for example.
> >>
> >> I'm going to cautiously disagree. If the CPU needed was scaled so it
> >> represented a fixed number of cycles (operations, work units) then the
> >> effect of faster CPU would be shown. And the total power of all attached
> >> CPUs should be taken into account, using HT or SMP does have an effect
> >> of feel.
> >
> > That is rather hard to do because each architecture's interpretation of
> > fixed number of cycles is different and this doesn't represent their
> > speed in the real world. The calculation when interbench is first run to
> > see how many "loops per ms" took quite a bit of effort to find just how
> > many loops each different cpu would do per ms and then find a way to make
> > that not change through compiler optimised code. The "loops per ms"
> > parameter did not end up being proportional to cpu Mhz except on the same
> > cpu type.
>
> right, but the amount of cpu required to do a specific task will also vary
> significantly between CPU families for the same task as well. as long as
> the loops don't get optimized away by the compiler I think you can setup
> some loops to do the same work on each CPU, even if they take
> significantly different amounts of time (as an off-the-wall, obviously
> untested example you could make your 'loop' be a calculation of Pi and for
> the 'audio' test you compute the first 100 digits, for the video test you
> compute the first 1000 digits, and for the X test you compute a random
> number of digits between 10 and 1)

Once again I don't disagree, and the current system of loops_per_ms does 
exactly that and can be simply used as a fixed number of loops already. My 
point was there'd be argument about what sort of "loop" or load should be 
used as each cpu type would do different "loops" faster and they won't 
necessarily represent video, audio or X in the real world. Currently the loop 
in interbench is simply:
for (i = 0 ; i < loops ; i++)
 asm volatile("" : : : "memory");

and if noone argues i can use that for fixed workload.

Cheers,
Con


pgp5yqdG4Iw3o.pgp
Description: PGP signature

Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark

[Con Kolivas]

On Thu, 14 Jul 2005 03:54, Bill Davidsen wrote:
> Con Kolivas wrote:
> > On Tue, 12 Jul 2005 21:57, David Lang wrote:
> >>for audio and video this would seem to be a fairly simple scaleing factor
> >>(or just doing a fixed amount of work rather then a fixed percentage of
> >>the CPU worth of work), however for X it is probably much more
> >> complicated (is the X load really linearly random in how much work it
> >> does, or is it weighted towards small amounts with occasional large
> >> amounts hitting? I would guess that at least beyond a certin point the
> >> liklyhood of that much work being needed would be lower)
> >
> > Actually I don't disagree. What I mean by hardware changes is more along
> > the lines of changing the hard disk type in the same setup. That's what I
> > mean by careful with the benchmarking. Taking the results from an athlon
> > XP and comparing it to an altix is silly for example.
>
> I'm going to cautiously disagree. If the CPU needed was scaled so it
> represented a fixed number of cycles (operations, work units) then the
> effect of faster CPU would be shown. And the total power of all attached
> CPUs should be taken into account, using HT or SMP does have an effect
> of feel.

That is rather hard to do because each architecture's interpretation of fixed 
number of cycles is different and this doesn't represent their speed in the 
real world. The calculation when interbench is first run to see how many 
"loops per ms" took quite a bit of effort to find just how many loops each 
different cpu would do per ms and then find a way to make that not change 
through compiler optimised code. The "loops per ms" parameter did not end up 
being proportional to cpu Mhz except on the same cpu type.

> Disk tests should be at a fixed rate, not all you can do. That's NOT
> realistic.

Not true; what you suggest is another thing to check entirely, and that would 
be a valid benchmark too. What I'm interested in is what happens if you read 
or write a DVD ISO image for example to your hard disk and what this does to 
interactivity. This sort of reading or writing is not throttled in real life.

Cheers,
Con


pgp47n8JDw6cO.pgp
Description: PGP signature

Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark

[Con Kolivas]

On Thu, 14 Jul 2005 03:34, Lee Revell wrote:
> On Wed, 2005-07-13 at 13:27 +0200, szonyi calin wrote:
> > I have the following problem with audio:
> > Xmms is running with threads for audio and spectrum
> > analyzer(OpenGL).
> > The audio eats 5% cpu, the spectrum analyzer about 80 %. The
> > problem is that sometimes the spectrum analyzer is eating all of
> > the cpu while the audio is skipping. Xmms is version 1.2.10
> > kernel is vanilla, latest "stable" version 2.6.12, suid root.
> >
> > Does your benchmark simultes this kind of behaviour ?
>
> That's just a broken app, the kernel can't do anything about it.  XMMS
> should not be running the spectrum analyzer thread at such a high
> priority as to interfere with the audio thread.

I agree; optimising for this is just silly.

Cheers,
Con


pgpnIs5lJKznX.pgp
Description: PGP signature

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Con Kolivas]

On Thu, 14 Jul 2005 05:10, Linus Torvalds wrote:
> On Wed, 13 Jul 2005, Vojtech Pavlik wrote:
> > No, but 1/1000Hz = 100ns, while 1/864Hz = 1157407.407ns. If you have
> > a counter that counts the ticks in nanoseconds (xtime ...), the first
> > will be exact, the second will be accumulating an error.
>
> It's not even that we have a counter like that, it's the simple fact that
> we have a standard interface to user space that is based on milli-, micro-
> and nanoseconds.
>
> (For "poll()", "struct timeval" and "struct timespec" respectively).
>
> It's totally pointless saying that we can do 864 Hz "exactly", when the
> fact is that all the timeouts we ever get from user space aren't in that
> format. So the only thing that matters is how close to a millisecond we
> can get, not how close to some random number.

That may be the case but when I've measured the actual delay of schedule 
timeout when using nanosleep from userspace, the average at 1000Hz was 1.4ms 
+/- 1.5 sd . When we're expecting a sleep of "up to 1ms" we're getting 50% 
longer than the longest expected. Purely mathematically the accuracy of 
changing HZ from 1000 -> 864 will not bring with it any significant change to 
the accuracy. This can easily be measured as well to confirm. 

Using schedule timeout as an argument against it doesn't hold for me. 
Vojtech's comment of :
> "No, but 1/1000Hz = 100ns, while 1/864Hz = 1157407.407ns. If you have a 
> counter that counts the ticks in nanoseconds (xtime ...), the first will be 
> exact, the second will be accumulating an error." 
is probably the most valid argument against such a funky number. 

Cheers,
Con


pgp7HVxpTyLUV.pgp
Description: PGP signature

Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark

[Con Kolivas]

On Wed, 13 Jul 2005 06:55, Al Boldi wrote:
> On Tue, 12 Jul 2005, Con Kolivas wrote:
> > It runs a real time high priority timing thread that wakes up the thread
>
> Nice, but why is it threaded?

Because I'm an amateur, and I had to start somewhere.

> Forking would be more realistic!

Something for the future would be to fork the background workload separately 
from the benchmarked workload. Having them all in the same mm does appear to 
cause other interactions which pollute the real time data as Ingo has pointed 
out to me privately.

I'm a little burnt out from the effort so far so it can wait.

Thanks for feedback.

Cheers,
Con


pgpbcI9Z926x1.pgp
Description: PGP signature

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Con Kolivas]

On Wed, 13 Jul 2005 00:57, Lee Revell wrote:
> On Tue, 2005-07-12 at 21:52 +1000, Con Kolivas wrote:
> > > Well, it's just the default settings of the kernel which has changed.
> > > If you want the old behaviour, you can use (with your admin hat): echo
> > > 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice IMHO it
> > > seems quite fair, if you have a process nice'd to 10 it probably means
> > > you are not in a hurry.
> >
> > That's not necessarily true. Most people use 'nice' to have the cpu bound
> > task not affect their foreground applications, _not_ because they don't
> > care how long they take.
>
> But the scheduler should do this on its own!

That is a most unusual thing to tell the person who tuned the crap out of the 
2.6 scheduler so that it would do this.

> If people are having to 
> renice kernel compiles to maintain decent interactive performance (and
> yes, I have to do the same thing sometimes) the scheduler is BROKEN,
> period.

Two tasks being the same nice level still implies they should receive the same 
proportion of cpu. Anything else breaks the implied fairness of nice levels. 
Whether you agree with this approach or not, it is expected. No, cpu 
distribution is never _perfectly_ split 50/50 when nice levels are the same 
but we try our best to do so while maintaining interactivity. 

A more useful argument would be that you'd like to have two sets of nice 
levels - one perhaps called latnice implying which tasks you want latency 
critical but still want to have the same cpu and one called cpunice which 
affects the amount of cpu but not the latency. Some would like complete 
control over both nices while others want the scheduler to do everything for 
them. Either way, you want a compile to be both latnice and cpunice. Our 
current nice is both latnice and cpunice, and if nice levels are equal the 
scheduler does a heck of a lot of its own latnice based on behaviour. It's 
not perfect and nothing ever is. 

Cheers,
Con


pgpBuI8IR67F2.pgp
Description: PGP signature

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Con Kolivas]

On Tue, 12 Jul 2005 22:39, Con Kolivas wrote:
> On Tue, 12 Jul 2005 22:10, Vojtech Pavlik wrote:
> > The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
> > and is divided by 12 to get PIT tick rate
> >
> > 14.3181818 MHz / 12 = 1193182 Hz
> >
> > The reality is that the crystal is usually off by 50-100 ppm from the
> > standard value, depending on temperature.
> >
> > HZ   ticks/jiffie  1 second  error (ppm)
> > ---
> >100  11932  1.15238  15.2
> >200   5966  1.15238  15.2
> >250   4773  1.57143  57.1
> >300   3977  0.31429 -68.6
> >333   3583  0.64114 -35.9
> >500   2386  0.999847619-152.4
> >   1000   1193  0.999847619-152.4
> >
> > Some HZ values indeed fit the tick frequency better than others, up to
> > 333 the error is lost in the physical error of the crystal, for 500 and
> > 1000, it definitely is larger, and thus noticeable.
> >
> > Some (less round and nice) values of HZ would fit even better:
> >
> > HZ   ticks/jiffie  1 second  error (ppm)
> > ---
> > 82  14551  1.00152   0.2
>
> Most interesting... Would 838 Hz be a much better choice than 1000 then?
> (apart from the ugliness).

Duh I should have looked lower where you suggested 864, sorry.

   864   1381  1.01829   1.8

Cheers,
Con


pgpwmBsLS7Qqe.pgp
Description: PGP signature

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Con Kolivas]

On Tue, 12 Jul 2005 22:10, Vojtech Pavlik wrote:
> The PIT crystal runs at 14.3181818 MHz (CGA dotclock, found on ISA, ...)
> and is divided by 12 to get PIT tick rate
>
>   14.3181818 MHz / 12 = 1193182 Hz
>
> The reality is that the crystal is usually off by 50-100 ppm from the
> standard value, depending on temperature.
>
> HZ   ticks/jiffie  1 second  error (ppm)
> ---
>100  11932  1.15238  15.2
>200   5966  1.15238  15.2
>250   4773  1.57143  57.1
>300   3977  0.31429 -68.6
>333   3583  0.64114 -35.9
>500   2386  0.999847619-152.4
>   1000   1193  0.999847619-152.4
>
> Some HZ values indeed fit the tick frequency better than others, up to
> 333 the error is lost in the physical error of the crystal, for 500 and
> 1000, it definitely is larger, and thus noticeable.
>
> Some (less round and nice) values of HZ would fit even better:
>
> HZ   ticks/jiffie  1 second  error (ppm)
> ---
> 82  14551  1.00152   0.2


Most interesting... Would 838 Hz be a much better choice than 1000 then? 
(apart from the ugliness).

Cheers,
COn


pgp6GhxS6FV3X.pgp
Description: PGP signature

Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark

[Con Kolivas]

On Tue, 12 Jul 2005 22:17, David Lang wrote:
> which brings up another possible config option/test case, changing the
> read/write tests to try to do X MB/sec rather then the max possible speed
> (probably defaulting to max if nothing is specified)

That's a good idea. I was planning on adding a configurable cpu%/interval 
benchmark as well so configurable read/write is a logical addition. 

> thanks again for working to define a good test case

You're welcome, and thanks for feedback.

Cheers,
Con


pgprvKra3meq3.pgp
Description: PGP signature

Re: [ANNOUNCE] Interbench v0.20 - Interactivity benchmark

[Con Kolivas]

On Tue, 12 Jul 2005 21:57, David Lang wrote:
> this looks very interesting, however one thing that looks odd to me in
> this is the thought of comparing the results for significantly different
> hardware.
>
> for some of the loads you really are going to be independant of the speed
> of the hardware (burn, compile, etc will use whatever you have) however
> for others (X, audio, video) saying that they take a specific percentage
> of the cpu doesn't seem right.
>
> if I have a 400MHz cpu each of these will take a much larger percentage of
> the cpu to get the job done then if I have a 4GHz cpu for example.
>
> for audio and video this would seem to be a fairly simple scaleing factor
> (or just doing a fixed amount of work rather then a fixed percentage of
> the CPU worth of work), however for X it is probably much more complicated
> (is the X load really linearly random in how much work it does, or is it
> weighted towards small amounts with occasional large amounts hitting? I
> would guess that at least beyond a certin point the liklyhood of that much
> work being needed would be lower)

Actually I don't disagree. What I mean by hardware changes is more along the 
lines of changing the hard disk type in the same setup. That's what I mean by 
careful with the benchmarking. Taking the results from an athlon XP and 
comparing it to an altix is silly for example.

Cheers,
Con


pgpKkxQl7OqzM.pgp
Description: PGP signature

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Con Kolivas]

On Tue, 12 Jul 2005 21:49, Eric Piel wrote:
> 07/12/2005 01:11 PM, Ken Moffat wrote/a écrit:
> > On Tue, 12 Jul 2005, Ken Moffat wrote:
> >> I was going to say that niceness didn't affect what I was doing, but
> >>I've just rerun it [ in 2.6.11.9 ] and I see that tar and bzip2 show up
> >>with a niceness of 10.  I'm starting to feel a bit out of my depth here
> >
> > OK, Con was right, and I didn't initially make the connection.
> >
> >  In 2.6.11, untarring a .tar.bz2 causes tar and bzip2 to run with a
> > niceness of 10, but everything is fine.
> >
> >  In 2.6.12, ondemand _only_ has an effect for me in this example if I
> > put on my admin hat and renice the bzip2 process (tried 0, that works) -
> > renicing the tar process has no effect (obviously, that part doesn't
> > push the processor).
> >
> > So, from a user's point of view it's broken.
>
> Well, it's just the default settings of the kernel which has changed. If
> you want the old behaviour, you can use (with your admin hat):
> echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice
> IMHO it seems quite fair, if you have a process nice'd to 10 it probably
> means you are not in a hurry.

That's not necessarily true. Most people use 'nice' to have the cpu bound task 
not affect their foreground applications, _not_ because they don't care how 
long they take. I nice my kernel compiles and keep web browsing etc (actually 
I run them SCHED_BATCH but this has the same effect with the default ondemand 
governor now).

>
> Just by couriosity, I wonder how your processes are automatically
> reniced to 10 ?

Shell environment settings.

Cheers,
Con


pgpFi67GiEyeo.pgp
Description: PGP signature

[ANNOUNCE] Interbench v0.20 - Interactivity benchmark

[Con Kolivas]

   10 100100
Burn  0.518 +/- 30600452 100 99
Write 0.031 +/- 0.209   2.58 100100
Read  0.006 +/- 0.00173 0.01 100100
Compile4.59 +/- 5.74 42696.5 94
Memload   0.021 +/- 0.0697 0.659 100100

--- Benchmarking Video in the presence of loads ---
Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.003 +/- 0  0.005 100100
X  3.27 +/- 3.2 41.388.8   77.7
Burn  0.003 +/- 0.001  0.005 100100
Write 0.151 +/- 0.67  5099.5 99
Read  0.004 +/- 0.001730.037 100100
Compile   0.025 +/- 0.248   4.81 100100
Memload   0.018 +/- 0.0572 0.715 100100

--- Benchmarking X in the presence of loads ---
Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.009 +/- 0.0966 1 100 99
Video  4.46 +/- 4.43 57291.9 66
Burn   1.58 +/- 1.58 156 100 98
Write 0.002 +/- 0.0237 4 100 98
Read  0.008 +/- 0.079715 100 96
Compile   0.009 +/- 0.0896 2 100 99
Memload   0.108 +/- 0.13  10 100 98


Benchmarking kernel 2.6.12-rc6-ck1 with datestamp 200507121345

--- Benchmarking Audio in the presence of loads ---
Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.003 +/- 0  0.005 100100
Video 0.003 +/- 0  0.004 100100
X  2.53 +/- 3.01  11 100100
Burn  0.294 +/- 1.47  11 100100
Write 0.025 +/- 0.116   1.02 100100
Read  0.007 +/- 0.001   0.01 100100
Compile   0.393 +/- 1.68  11 100100
Memload   0.095 +/- 0.545  6 100100

--- Benchmarking Video in the presence of loads ---
Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.003 +/- 0.002450.052 100100
X  3.57 +/- 3.2122.795.7   91.3
Burn  0.837 +/- 2.49  5097.7   95.5
Write 0.094 +/- 0.596   16.7 100   99.8
Read  0.005 +/- 0.008720.169 100100
Compile   0.543 +/- 1.9133.398.8   97.7
Memload0.21 +/- 0.836   16.799.7   99.3

--- Benchmarking X in the presence of loads ---
Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.009 +/- 0.0964 1 100 99
Video  2.31 +/- 2.27 75490.9 65
Burn  0.129 +/- 0.151 12 100 98
Write 0.069 +/- 0.112  6 100 98
Read  0.009 +/- 0.0896 1 100 99
Compile   0.039 +/- 0.102  3 100 98
Memload   0.004 +/- 0.0408 1 100 99


The full logs are available here (including niced runs and real time runs):
http://ck.kolivas.org/apps/interbench/2.6.13-rc1.log
http://ck.kolivas.org/apps/interbench/2.6.12-rc6-ck1.log

Thanks:
For help from Zwane Mwaikambo, Bert Hubert, Seth Arnold, Rik Van Riel,  
Nicholas Miell and John Levon. Aggelos Economopoulos for contest code, and
Bob Matthews for irman (mem_load) code.

This was quite some time in the making... I realise there's so much more that 
could be done trying to simulate the interactive tasks and the loads, but 
this is a start, it's quite standardised and the results are reproducible. 
Adding more code to simulate loads and threads to benchmark is quite easy if 
someone wishes to suggest or code up something I'm all ears. Of course 
bugfixes, comments and suggestions are most welcome.

Cheers,
Con Kolivas


pgp5azDei48nW.pgp
Description: PGP signature

Re: ondemand cpufreq ineffective in 2.6.12 ?

[Con Kolivas]

On Tue, 12 Jul 2005 05:45, Ken Moffat wrote:
> On Mon, 11 Jul 2005, Ken Moffat wrote:
> > Hi,
> >
> >  I've been using the ondemand governor on athlon64 winchesters for a few
> > weeks.  I've just noticed that in 2.6.12 the frequency is not
> > increasing under load, it remains at the lowest frequency.  This seems
> > to be down to something in 2.6.12-rc6, but I've seen at least one report
> > since then that ondemand works fine.  Anybody else seeing this problem ?
>
>  And just for the record, it's still not working in 2.6.13-rc2.  Oh
> well, back to 2.6.11 for this box.

I noticed a change in ondemand on pentiumM, where it would not ramp up if the 
task using cpu was +niced. It does ramp up if the task is not niced. This 
seems to have been considered all round better but at my end it is not - if 
it takes the same number of cycles to complete a task it does not save any 
battery running it at 600Mhz vs 1700Mhz, it just takes longer. Yes I know 
during the initial ramp up the 1700Mhz one will waste more battery, but that 
is miniscule compared to something that burns cpu constantly for 10 mins. Now 
I'm forced to run my background tasks at nice 0 and not get the benefit of 
nicing the tasks, _or_ I have to go diddling with settings in /sys to disable 
this feature or temporarily move to the performance governor. Although I 
complained lightly initially when this change was suggested, I didn't realise 
it was actually going to become standard. 

To me the ondemand governor was supposed to not delay you at all, but cause as 
much battery saving as possible without noticeable slowdown...

Oh well you can't please everyone all the time. 

Con


pgp0qHraEd2De.pgp
Description: PGP signature

Re: 2.6.12-ck3

[Con Kolivas]

On Fri, 8 Jul 2005 07:30 am, Rudo Thomas wrote:
> Hi again.
>
> > Time seems to pass very fast with this kernel.
>
> dmesg output has not revealed anything extraordinary...
>
> Am I the only one who gets this strange behaviour? Kernel's notion of
> time seems to be about 30 times faster than real time.
>
> I will gladly provide any information that will help sorting this
> problem out.

Sorry I really have no idea. If you can retest with latest stable mainline 
that this kernel is based on (2.6.12.2) and reproduce the problem, then 
posting that info along with a summary of your 'lspci -vv' and 'dmesg' 
and .config might be helpful as out-of-kernel patchsets are often ignored by 
most developers apart from the maintainer (ie me in this case.)

Cheers,
Con
-
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: rt-preempt build failure

[Con Kolivas]

On Wed, 6 Jul 2005 23:49, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > thanks, i have fixed this and have uploaded the -51-00 patch.
> >
> > Thanks. boots and runs stable after a swag of these initially
> > (?netconsole related):

> ok, the patch below (or -51-04 and later kernels) should fix this one.
> printk is fully preemptible from now on - lets see how it works out in
> practice. (i kept it under irqs-off to make sure we get all crash
> messages out. Perhaps we could disable irqs/preemption if
> oops_in_progress?) This patch should also fix similar, fbcon related
> messages.

Works fine, thanks!

Con
-
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: rt-preempt build failure

[Con Kolivas]

On Tue, 5 Jul 2005 23:51, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > Hi Ingo
> >
> > This config on i386:
> > http://ck.kolivas.org/crap/rt-config
> >
> > realtime-preempt-2.6.12-final-V0.7.50-51
> > fails to build with these errors:
>
> thanks, i have fixed this and have uploaded the -51-00 patch.

Thanks. boots and runs stable after a swag of these initially (?netconsole 
related):

BUG: scheduling with irqs disabled: swapper/0x/1
caller is __down_mutex+0x143/0x200
 [] schedule+0x95/0xf5 (8)
 [] __down_mutex+0x143/0x200 (28)
 [] b44_start_xmit+0x23/0x3ee (84)
 [] find_skb+0xa4/0xe4 (8)
 [] netpoll_send_skb+0x13/0xb0 (48)
 [] write_msg+0x5f/0xb6 (16)
 [] write_msg+0x0/0xb6 (12)
 [] __call_console_drivers+0x41/0x4d (8)
 [] call_console_drivers+0xec/0x109 (20)
 [] release_console_sem+0x24/0xd4 (32)
 [] init_netconsole+0x40/0x74 (24)
 [] do_initcalls+0x55/0xc7 (12)
 [] init+0x8a/0x1b3 (32)
 [] init+0x0/0x1b3 (16)
 [] kernel_thread_helper+0x5/0xb (8)

There's a 75KB dmesg with all of them (not sure if any differ) here:
http://ck.kolivas.org/crap/rt.dmesg

same config:
http://ck.kolivas.org/crap/rt-config

Cheers,
Con


pgpuL5AOGp8v3.pgp
Description: PGP signature

rt-preempt build failure

[Con Kolivas]

Hi Ingo

This config on i386:
http://ck.kolivas.org/crap/rt-config

realtime-preempt-2.6.12-final-V0.7.50-51
fails to build with these errors:

kernel/rt.c: In function `__down_mutex':
kernel/rt.c:1264: error: `ti' undeclared (first use in this function)
kernel/rt.c:1264: error: (Each undeclared identifier is reported only once
kernel/rt.c:1264: error: for each function it appears in.)
kernel/rt.c:1264: error: `task' undeclared (first use in this function)
kernel/rt.c:1264: error: `old_owner' undeclared (first use in this function)
kernel/rt.c:1264: error: too many arguments to function `down_mutex'
kernel/rt.c: In function `__down':
kernel/rt.c:1269: error: `ti' undeclared (first use in this function)
kernel/rt.c:1269: error: `task' undeclared (first use in this function)
kernel/rt.c:1269: error: `old_owner' undeclared (first use in this function)
kernel/rt.c:1269: error: too many arguments to function `down'

Cheers,
Con


pgpyMSy6F1YiR.pgp
Description: PGP signature

Re: [ANNOUNCE][RFC] PlugSched-5.2.1 for 2.6.11 and 2.6.12

[Con Kolivas]

On Tue, 5 Jul 2005 21:25, Peter Williams wrote:
> Con Kolivas wrote:
> > On Tue, 5 Jul 2005 17:46, Peter Williams wrote:
> >>Peter Williams wrote:
> >>>Con Kolivas wrote:
> >>>>On Mon, 20 Jun 2005 15:33, Peter Williams wrote:
> >>>>>PlugSched-5.2.1 is available for 2.6.11 and 2.6.12 kernels.  This
> >>>>>version applies Con Kolivas's latest modifications to his "nice" aware
> >>>>>SMP load balancing patches.
> >>>>
> >>>>Thanks Peter.
> >>>>Any word from your own testing/testers on how well smp nice balancing
> >>>>is working for them now?
> >>>
> >>>No, they got side tracked onto something else but should start working
> >>>on it again soon.  I'll give them a prod :-)
> >>
> >>Con,
> >>We've done some more testing with this with results that are still
> >>disappointing.
> >
> > Is this with the migration thread accounted patch as well?

The results from smp nice I've received so far show that a 30% slowdown 
(instead of 5% on uniprocessor) occurs to high priority tasks in the presence 
of low priority tasks worst case scenario when the tasks sleep frequently. 
However excellent smp nice support with negligible slowdown occurs (ie nice 
is well respected) when the tasks are fully cpu bound. This suggests that 
what is happening on task wakeup is the limiting factor with this smp nice 
implementation. This makes sense given that most of the balancing occurs 
during busy rebalance when the queues are busy. I tried ignoring the length 
of queue (ie not having the single task running check for idle rebalance) and 
while this improved the nice effect substantially, it also cost us heavily in 
throughput making it unwarranted.

Cheers,
Con
-
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: [ANNOUNCE][RFC] PlugSched-5.2.1 for 2.6.11 and 2.6.12

[Con Kolivas]

On Tue, 5 Jul 2005 17:46, Peter Williams wrote:
> Peter Williams wrote:
> > Con Kolivas wrote:
> >> On Mon, 20 Jun 2005 15:33, Peter Williams wrote:
> >>> PlugSched-5.2.1 is available for 2.6.11 and 2.6.12 kernels.  This
> >>> version applies Con Kolivas's latest modifications to his "nice" aware
> >>> SMP load balancing patches.
> >>
> >> Thanks Peter.
> >> Any word from your own testing/testers on how well smp nice balancing
> >> is working for them now?
> >
> > No, they got side tracked onto something else but should start working
> > on it again soon.  I'll give them a prod :-)
>
> Con,
>   We've done some more testing with this with results that are still
> disappointing. 

Is this with the migration thread accounted patch as well?

Con
-
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/

[Patch] Staircase cpu scheduler v11

[Con Kolivas]

The staircase single priority array foreground/background cpu scheduler has 
been updated to version 11.

Numerous minor behavioural issues have been abolished with a much cleaner 
simple mathematical priority elevation/dropping mechanism and virtually no 
"interactivity estimation" algorithms exist in the design. Behaviour across 
all loads appears to have been improved with this.

Worst case latencies have been much improved with in-kernel work on behalf of 
user processes being debited from the user processes.

Lots of micro-optimisations were added and throughput has improved.

All forms of gaming and audio issues appear to have been abolished.

A rolled up patch for 2.6.11 is here:
http://ck.kolivas.org/patches/2.6/2.6.11/2.6.11_to_staircase11.diff

and an incremental from 2.6.11-ck4 to staircase 11 is here:
http://ck.kolivas.org/patches/2.6/2.6.11/2.6.11-ck4_to_staircase11.diff

The next -ck release will use this as its base.

Thanks to all the people testing this work and giving feedback.

Cheers,
Con


pgpGuFUYpP4Il.pgp
Description: PGP signature

2.6.11-ck4

[Con Kolivas]

These are patches designed to improve system responsiveness. It is 
configurable to any workload but the default ck* patch is aimed at the 
desktop and ck*-server is available with more emphasis on serverspace.

Apply to 2.6.11:
http://ck.kolivas.org/patches/2.6/2.6.11/2.6.11-ck4/patch-2.6.11-ck4.bz2
http://ck.kolivas.org/patches/2.6/2.6.11/2.6.11-ck4/patch-2.6.11-ck4-server.bz2

web:
http://kernel.kolivas.org
all patches:
http://ck.kolivas.org/patches/
Split patches available.


Changes since 2.6.11-ck2 (last public announcement):

Changed:
~schediso2.12.diff
Small policy fix to ensure real time tasks without privileges get dropped to 
SCHED_ISO


Added:
+cfq-ts21-fix1.diff
+cfq-ts21-fix2.diff
Two small cfq bugfixes

+s10.6_s10.7.diff
Micro-optimisations for staircase cpu scheduler

+patch-2.6.11.7
Latest stable version

+2611ck4-version.diff
Version


Removed:
-nvidia_6111-6629_compat2.diff
Nvidia compatibility no longer required with new nvidia driver

-patch-2.6.11.1
-patch-2.6.11.2
-2611ck2-version.diff
obvious


Full patchlist:
 2.6.11_to_staircase10.5.diff
 s10.5_s10.6.diff
 s10.6_s10.7.diff
Latest version of the staircase O(1) single priority array 
foreground-background cpu scheduler

 schedrange.diff
Eases addition of scheduling policies

 schedbatch2.7.diff
Idle cpu scheduling

 schediso2.12.diff
Unprivileged low latency cpu scheduling

 mapped_watermark3.diff
Lighter memory scanning under light loads and far less swapping

 1g_lowmem1_i386.diff
Support 1GB of memory without enabling HIGHMEM

 cddvd-cmdfilter-drop.patch
Support normal user burning of cds

 cfq-ts-21.diff
 cfq-ts21-fix.diff
 cfq-ts21-fix1.diff
 cfq-ts21-fix2.diff
Complete fair queueing timeslice i/o scheduler v21

 defaultcfq.diff
Enable the cfq I/O scheduler by default (-ck)

default_deadline.diff 
Enable the deadline I/O scheduler by default (-server)

 isobatch_ionice2.diff
Support for i/o priorities suitable for SCHED_ISO and SCHED_BATCH tasks

 rt_ionice.diff
Support for i/o priority suitable for real time tasks

 patch-2.6.11.7
The latest stable tree.

 2611ck4-version.diff
Version

and available separately in the patches/ dir as an addon:
 supermount-ng208-2611.diff
Simplest way to automount removable media


And don't forget to pour one of these before booting this kernel:
http://ck.kolivas.org/patches/2.6/2.6.11/cognac.JPG


Cheers,
Con
 


pgp05SgPDKeKS.pgp
Description: PGP signature

2.6.11-ck2

[Con Kolivas]

These are patches designed to improve system responsiveness. It is 
configurable to any workload but the default ck* patch is aimed at the 
desktop and ck*-server is available with more emphasis on serverspace.

http://ck.kolivas.org/patches/2.6/2.6.11/2.6.11-ck2/patch-2.6.11-ck2.bz2

web:
http://kernel.kolivas.org
all patches:
http://ck.kolivas.org/patches/
Split patches and a server specific patch available.


Note:
Please do not set the mapped value any higher than the default (66) with a 
hardmaplimit on. This will bring an out of memory condition easily. Try the 
default setting and you'll find it avoids swap much more aggressively than 
higher mapped settings did on previous versions.


Added since 2.6.11-ck1:
+s10.5_s10.6.diff
Staircase scheduler update. Somehow the merge from 2.6.10-staircase10.5 to 
2.6.11 included an experimental change that was never meant to be part of 
staircase10.5. This patch removes that change so brings it back to the 10.5 
design. Some slowdown was experienced over time on slower hardware and this 
patch fixes it. To avoid confusion the version number has been updated. 
Thanks to Martin Josefsson for tracking this down!

+cfq-ts21-fix.diff
Jens had some fixes to the latest cfq-ts code that hadn't yet made it to my 
tree. This brings it in line with his current stable tree.

+patch-2.6.11.1
+patch-2.6.11.2
The obvious and security fixes tree.

+2611ck2-version.diff
Version


Removed:
-2611ck1-version.diff


Full patchlist:
 2.6.11_to_staircase10.5.diff
Latest version of the staircase O(1) single priority array 
foreground-background cpu scheduler

 schedrange.diff
Eases addition of scheduling policies

 schedbatch2.7.diff
Idle cpu scheduling

 schediso2.11.diff
Unprivileged low latency cpu scheduling

 mapped_watermark3.diff
Lighter memory scanning under light loads and far less swapping

 1g_lowmem1_i386.diff
Support 1GB of memory without enabling HIGHMEM

 cddvd-cmdfilter-drop.patch
Support normal user burning of cds

 nvidia_6111-6629_compat2.diff
Make nvidia compile support easier. Note to build the actual module you need 
to manually extract the NVIDIA_kernel file and patch (-p0) one of the  
relevant compatibility patches from here:
http://ck.kolivas.org/patches/2.6/2.6.11/NVIDIA_kernel-1.0-6111-1132076.diff
http://ck.kolivas.org/patches/2.6/2.6.11/NVIDIA_kernel-1.0-6629-1201042.diff

 cfq-ts-21.diff
Complete fair queueing timeslice i/o scheduler v21

 defaultcfq.diff
Enable the cfq I/O scheduler by default

 isobatch_ionice2.diff
Support for i/o priorities suitable for SCHED_ISO and SCHED_BATCH tasks

 rt_ionice.diff
Support for i/o priority suitable for real time tasks

 s10.5_s10.6.diff
Staircase scheduler update.

 cfq-ts21-fix.diff
Jens had some fixes to the latest cfq-ts code that hadn't yet made it to my 
tree. This brings it in line with his current stable tree.

 patch-2.6.11.1
 patch-2.6.11.2
The obvious and security fixes tree.

 2611ck2-version.diff
Version

and available separately in the patches/ dir as an addon:
 supermount-ng208-2611.diff
Simplest way to automount removable media


And don't forget to pour one of these before booting this kernel:
http://ck.kolivas.org/patches/2.6/2.6.11/cognac.JPG


Cheers,
Con


pgpgSZLRdzdCQ.pgp
Description: PGP signature

2.6.11-ck1

[Con Kolivas]

These are patches designed to improve system responsiveness. It is 
configurable to any workload but the default ck* patch is aimed at the 
desktop and ck*-server is available with more emphasis on serverspace.

http://ck.kolivas.org/patches/2.6/2.6.11/2.6.11-ck1/patch-2.6.11-ck1.bz2

web:
http://kernel.kolivas.org
all patches:
http://ck.kolivas.org/patches/
Split patches and a server specific patch available.


Added since 2.6.10-ck7:
+cfq-ts-21.diff
The latest version of Jens' cfq-timeslice i/o scheduler now heavily tested and 
with full read i/o priority support

+isobatch_ionice2.diff
Support for i/o priorities suitable for SCHED_ISO and SCHED_BATCH tasks

+rt_ionice.diff
Support for i/o priority suitable for real time tasks


Changed:
+schediso2.11.diff
The development of the 3.x series of Isochronous scheduling support did not 
reach full maturity and its features were no longer deemed desirable. This 
has a minor bugfix for the 2.10 version included previously instead.

+mapped_watermark3.diff
Finally I have tweaked the mapped watermark patch which makes for memory 
scanning to be progressively more aggressive the more stress/fragmentation it 
is under, to swap far less under all sorts of load (especially i/o load), yet 
not risk out-of-memory kills. 


Rolled up:
~2.6.10_to_staircase9.2.diff
~schedbatch2.6.diff
~schediso2.8.diff
~mwII.diff
~s9.2_s9.3.diff
~2.8_i2.9.diff
~9.3_s9.4.diff
~i2.9_i2.10.diff
~b2.6_b2.7.diff
~s9.4_s10.diff
~s10_test1.diff
~s10_s10.1.diff
~s10.1_s10.2.diff
~s10.2_s10.3.diff
~s10.3_s10.4.diff
~s10.4_s10.5.diff
All merged into their newer versions


Removed:
-patch-2.6.10-as6
-2.6.10-mingoll.diff
-vm-pageout-throttling.patch
-fix-ll-resume.diff
-1504_vmscan-writeback-pages.patch
-2610ck7-version.diff
All not required as included in 2.6.11 or deprecated


Full patchlist:
 2.6.11_to_staircase10.5.diff
Latest version of the staircase O(1) single priority array 
foreground-background cpu scheduler

 schedrange.diff
Eases addition of scheduling policies

 schedbatch2.7.diff
Idle cpu scheduling

 schediso2.11.diff
Unprivileged low latency cpu scheduling

 mapped_watermark3.diff
Lighter memory scanning under light loads and far less swapping

 1g_lowmem1_i386.diff
Support 1GB of memory without enabling HIGHMEM

 cddvd-cmdfilter-drop.patch
Support normal user burning of cds

 nvidia_6111-6629_compat2.diff
Make nvidia compile support easier. Note to build the actual module you need 
to manually extract the NVIDIA_kernel file and patch (-p0) one of the  
relevant compatibility patches from here:
http://ck.kolivas.org/patches/2.6/2.6.11/NVIDIA_kernel-1.0-6111-1132076.diff
http://ck.kolivas.org/patches/2.6/2.6.11/NVIDIA_kernel-1.0-6629-1201042.diff

 cfq-ts-21.diff
Complete fair queueing timeslice i/o scheduler v21

 defaultcfq.diff
Enable the cfq I/O scheduler by default

 isobatch_ionice2.diff
Support for i/o priorities suitable for SCHED_ISO and SCHED_BATCH tasks

 rt_ionice.diff
Support for i/o priority suitable for real time tasks

 2611ck1-version.diff
version

and available separately in the patches/ dir as an addon:
 supermount-ng208-2611.diff
Simplest way to automount removable media


And don't forget to pour one of these before booting this kernel:
http://ck.kolivas.org/patches/2.6/2.6.11/cognac.JPG


Cheers,
Con


pgpkw1YTQVoSR.pgp
Description: PGP signature

2.6.10-ck7

[Con Kolivas]

These are patches designed to improve system responsiveness. It is 
configurable to any workload but the default ck* patch is aimed at the 
desktop and ck*-server is available with more emphasis on serverspace.

This is a maintenance release and is identical to 2.6.10-ck6 apart from 
using 2.6.10-as6 with it's updated security and bugfixes for 2.6.10 
(thanks to Andres Salomon for maintaining this).

http://ck.kolivas.org/patches/2.6/2.6.10/2.6.10-ck7/


Full patchlist:
patch-2.6.10-as6
2.6.10_to_staircase9.2.diff
schedrange.diff
schedbatch2.6.diff
schediso2.8.diff
mwII.diff
1g_lowmem1_i386.diff
defaultcfq.diff
2.6.10-mingoll.diff
cddvd-cmdfilter-drop.patch
vm-pageout-throttling.patch
nvidia_6111-6629_compat2.diff
fix-ll-resume.diff
s9.2_s9.3.diff
i2.8_i2.9.diff
s9.3_s9.4.diff
i2.9_i2.10.diff
b2.6_b2.7.diff
s9.4_s10.diff
s10_test1.diff
s10_s10.1.diff
s10.1_s10.2.diff
s10.2_s10.3.diff
1504_vmscan-writeback-pages.patch
s10.3_s10.4.diff
s10.4_s10.5.diff
2610ck7-version.diff

and available separately:
supermount-ng208-10ck5.diff

Cheers,
Con


pgpjzP25BxBHI.pgp
Description: PGP signature

2.6.10-ck6

[Con Kolivas]

These are patches designed to improve system responsiveness. It is 
configurable to any workload but the default ck* patch is aimed at the 
desktop and ck*-server is available with more emphasis on serverspace.

This is a maintenance release and is identical to 2.6.10-ck5 apart from 
using 2.6.10-as5 with it's updated security and bugfixes for 2.6.10 
(thanks to Andres Salomon for maintaining this).

http://ck.kolivas.org/patches/2.6/2.6.10/2.6.10-ck6/
Full patchlist:
patch-2.6.10-as5
2.6.10_to_staircase9.2.diff
schedrange.diff
schedbatch2.6.diff
schediso2.8.diff
mwII.diff
1g_lowmem1_i386.diff
defaultcfq.diff
2.6.10-mingoll.diff
cddvd-cmdfilter-drop.patch
vm-pageout-throttling.patch
nvidia_6111-6629_compat2.diff
fix-ll-resume.diff
s9.2_s9.3.diff
i2.8_i2.9.diff
s9.3_s9.4.diff
i2.9_i2.10.diff
b2.6_b2.7.diff
s9.4_s10.diff
s10_test1.diff
s10_s10.1.diff
s10.1_s10.2.diff
s10.2_s10.3.diff
1504_vmscan-writeback-pages.patch
s10.3_s10.4.diff
s10.4_s10.5.diff
2610ck6-version.diff
and available separately:
supermount-ng208-10ck5.diff
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Werner Almesberger <[EMAIL PROTECTED]> writes:

[ Cc:s trimmed, added abiss-general ]
Con Kolivas wrote:
Possibly reiserfs journal related. That has larger non-preemptible code 
sections.
If I understand your workload right, it should consist mainly of
computation, networking (?), and disk reads.

The jack_test3.2 is basically a multiprocess realtime audio test.  A
fair amount of computation, signifcant task switch overhead, but
most I/O is to the sound card.
There's some disk activity starting clients and probably some other
system activity in the background.

I don't know much about ReiserFS, but in some experiments with ext3,
using ABISS, we found that a reader application competing with best
effort readers would experience worst-case delays of dozens of
milliseconds.
They were caused by journaled atime updates. Mounting the file
system with "noatime" reduced delays to a few hundred microseconds
(still worst-case).

Interesting. Worth a try to verify.  Con was seeing a 6msec delay
every 20 seconds.  This was devastating to the test, which tries to
run a full realtime audio cycle every 1.45msec.
They already were mounted noatime :(
Con


signature.asc
Description: OpenPGP digital signature

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Con Kolivas]

Paul Davis wrote:
	* real inter-process handoff. i am thinking of something like
	sched_yield(), but it would take a TID as the target
	of the yield. this would avoid all the crap we have to 
	go through to drive the graph of clients with FIFO's and
	write(2) and poll(2). Futexes might be a usable
	approximation in 2.6 (we are supporting 2.4, so we can't
	use them all the time)
yield_to(tid) should not be too hard to implement. Ingo? What do you think?
Con


signature.asc
Description: OpenPGP digital signature

Re: Linux hangs during IDE initialization at boot for 30 sec

[Con Kolivas]

Richard Hughes wrote:
Benjamin Herrenschmidt  kernel.crashing.org> writes:
This looks like bogus HW, or bogus list of IDE interfaces ...

How can I test to see if this is the case?

The IDE layer waits up to 30 seconds for a device to drop it's busy bit,
which is necessary for some drives that aren't fully initialized yet.

Sure, make sense.

I suspect in your case, it's reading "ff", which indicates either that
there is no hardware where the kernel tries to probe, or that there is
bogus IDE interfaces which don't properly have the D7 line pulled low so
that BUSY appears not set in absence of a drive.

Right. How do I find the value of D7?

I'm not sure how the list of intefaces is probed on this machine, that's
probably where the problem is.
I've read that people have had this problem go away if they disable this 
option:

< > generic/default IDE chipset support
If you have chipset support for your IDE controller this isn't needed, 
and I'd recommend disabling it. The "why" it made the problem go away is 
something I can't answer.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Good work. Looks like you're probably right about the accounting. It
may be as simple as the fact that it is on the timer tick that we're
getting rescheduled and this ends up being accounted as more since the
accounting happens only at the scheduler tick. A test run setting
iso_cpu at 100% should tell you if it's accounting related - however
the RLIMIT_RT_CPU patch is accounted in a similar way so I'm not sure
there isn't another bug hanging around. 

I'm afraid on my hardware it has been behaving just like SCHED_FIFO
for some time which is why I've been hanging on your results. 

My guess is that most of this test fits inside that huge cache of
yours, making it run much faster than on my system.  You probably need
to increase the number of clients to get comparable results.
Bah increasing the clients from 14 to 20 the script just fails in some 
meaningless way

Killed
[EMAIL PROTECTED] jack_test4.1]$ [1/1] jack_test4_client (17/20) stopped.
[1/1] jack_test4_client (18/20) stopped.
./run.sh: line 153:  7504 Broken pipe ${CMD} >>${LOG} 2>&1
[1/1] jack_test4_client ( 2/20) stopped.
./run.sh: line 153:  7507 Broken pipe ${CMD} >>${LOG} 2>&1
even before it starts :(
When you say just like SCHED_FIFO, do you mean completely clean?  Or
are you still getting unexplained xruns?  If that's the case, we need
to figure out why and eliminate them.
On my P4 with the results I posted I am getting no xruns whatsoever with 
either SCHED_FIFO or ISO. As for the pentiumM I've given up trying to 
use that for latency runs since even with everything shut down and the 
file system with journal off running SCHED_FIFO I get 8ms peaks every 20 
seconds. I'll keep blaming reiserfs for that one. Only dropping to 
single user mode and unmounting filesystems can get rid of them.

The reason I can measure an effect here is that the test is heavy
enough to stress my system and the system is RT-clean enough for
SCHED_FIFO to work properly.  (That's no surprise, I've been running
it that way for years.)
Yeah I understand. I'm kinda stuck with hardware that either doesn't 
have a problem, or an installation too flawed to use.

It did work better.  On the first run, there were a couple of real bad
xruns starting up.  But, the other two runs look fairly clean.
  http://www.joq.us/jack/benchmarks/sched-iso-fix.100
With a compile running, bad xruns and really long delays become a
serious problem again.
  http://www.joq.us/jack/benchmarks/sched-iso-fix.100+compile
Comparing the summary statistics with the 90% run, suggests that the
same problems occur in both cases, but not as often at 100%.
  http://www.joq.us/jack/benchmarks/.SUMMARY
With these latency demands, the system can't ever pick the wrong
thread on exit from even a single interrupt, or we're screwed.  I am
pretty well convinced this is not happening reliably (except with
SCHED_FIFO).
Looking at the code I see some bias towards keeping the cpu count too 
high (it decays too slowly) but your results confirm a bigger problem 
definitely exists. At 100% it should behave the same as SCHED_FIFO 
without mlock, and it is not in your test. I simply need to look at my 
code harder.

Cheers,
Con
-
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: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

[Con Kolivas]

Jack O'Quin wrote:
The fact that the results did improve with the 90% setting suggests
that there may be a bug in your throttling or time accounting.  The
DSP load for this test should hover around 50% when things are working
properly.  It should never hit a 70% limit, not even momentarily.  The
background compile should not affect that, either.
Something seems to be causing scheduling delays when the sound card
interrupt causes jackd to become runnable.  Ingo's nice(-20) patches
seem to have the same problem, but his RLIMIT_RT_CPU version does not.
Good work. Looks like you're probably right about the accounting. It may 
be as simple as the fact that it is on the timer tick that we're getting 
rescheduled and this ends up being accounted as more since the 
accounting happens only at the scheduler tick. A test run setting 
iso_cpu at 100% should tell you if it's accounting related - however the 
RLIMIT_RT_CPU patch is accounted in a similar way so I'm not sure there 
isn't another bug hanging around. I'm afraid on my hardware it has been 
behaving just like SCHED_FIFO for some time which is why I've been 
hanging on your results. You're not obliged to do anything (obviously), 
but the 100% run should help discriminate where the problem is.

Since I've come this far with the code I'll have another look for any 
other obvious bugs.

Cheers,
Con
-
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: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Sure enough I found the bug in less than 5 mins, and it would
definitely cause this terrible behaviour.
A silly bracket transposition error on my part :P

The corrected version works noticeably better, but still nowhere near
as well as SCHED_FIFO.  The first run had a cluster of really bad
xruns.  The second and third were much better, but still with numerous
small xruns.
  http://www.joq.us/jack/benchmarks/sched-iso-fix/
With a compile running in the background it was a complete failure.
Some kind of big xrun storm triggered a collapse on every attempt.
  http://www.joq.us/jack/benchmarks/sched-iso-fix+compile/
The summary statistics are mixed.  The delay_max is noticeably better
than before, but still much worse than SCHED_FIFO.  But, the xruns are
really bad news...
Excellent.
Believe it or not these look like good results to me. Your XRUNS are 
happening when the DSP load is >70% which is the iso_cpu % cutoff. Try 
setting the iso_cpu to 90%

echo 90 > /proc/sys/kernel/iso_cpu
Cheers,
Con
-
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: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

[Con Kolivas]

Jack O'Quin wrote:
Loading the realtime-lsm and then running with SCHED_FIFO *does* work
as expected on this kernel.  I should retry the test with *exactly*
the expected patch sequence.  What would that be?
Sure enough I found the bug in less than 5 mins, and it would definitely 
cause this terrible behaviour.

A silly bracket transposition error on my part :P
Cheers,
Con
Index: linux-2.6.11-rc2-iso/kernel/sched.c
===
--- linux-2.6.11-rc2-iso.orig/kernel/sched.c	2005-02-01 07:28:40.171079813 +1100
+++ linux-2.6.11-rc2-iso/kernel/sched.c	2005-02-01 07:29:21.332297160 +1100
@@ -326,9 +326,9 @@ static int task_preempts_curr(task_t *p,
 goto out;
 			}
 			p_prio = ISO_PRIO;
+		}
 		if (iso_task(rq->curr))
 			curr_prio = ISO_PRIO;
-		}
 	}
 out:
 	if (p_prio < curr_prio)


signature.asc
Description: OpenPGP digital signature

Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

While it is not clear what form the final soft real time
implementation is, we should complete the partial implementation of
SCHED_ISO that is in 2.6.11-rc2-mm1.

I finally had a chance to try this today.  I applied a slightly
different patch (2.6.11-rc2-iso3.diff) on top of patch-2.6.11-rc2.  I
tried to use 2.6.11-rc2-mm2, but could not due to conflicts with other
scheduler updates.
It is not clear whether the realtime threads are running in the new
scheduler class.  Checking with schedtool yields odd results.
(Before, my old schedtool always said "POLICY I: SCHED_ISO".)
[EMAIL PROTECTED] jack_test/ $ pst jackd
 2173  2173 TS   -   0  19   0  0.0 SLs  rt_sigsuspend  jackd
 2174  2174 ?   21   0  60   0  0.0 SL   -  jackd
 2175  2175 TS   -   0  23   0  0.0 SL   rt_sigsuspend  jackd
 2176  2176 TS   -   0  23   0  0.0 SL   -  jackd
 2177  2177 ?   20   0  59   0  0.0 SL   syscall_call   jackd
 2178  2178 ?   10   0  49   0  1.7 SL   -  jackd
[EMAIL PROTECTED] jack_test/ $ schedtool 2174 2176 2177 2178
PID  2174: PRIO  21, POLICY (null) , NICE  0
PID  2176: PRIO   0, POLICY N: SCHED_NORMAL, NICE  0
PID  2177: PRIO  20, POLICY (null) , NICE  0
PID  2178: PRIO  10, POLICY (null) , NICE  0
They're SCHED_ISO_FIFO which schedtool doesn't know about.
The results of the first run indicate something is badly wrong.  It is
quite possible that I got confused and messed up the build somehow.
  
http://www.joq.us/jack/benchmarks/sched-iso3/jack_test3-2.6.11-rc2-q1-200501311225.log
  
http://www.joq.us/jack/benchmarks/sched-iso3/jack_test3-2.6.11-rc2-q1-200501311225.png
Loading the realtime-lsm and then running with SCHED_FIFO *does* work
as expected on this kernel.  I should retry the test with *exactly*
the expected patch sequence.  What would that be?
Shouldn't matter. There must still be something wrong with my code... 
sigh. I'll look into it at some stage, but there doesn't seem much point.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

[PATCH] sched - Implement priority and fifo support for SCHED_ISO

[Con Kolivas]

While it is not clear what form the final soft real time implementation 
is, we should complete the partial implementation of SCHED_ISO that is 
in 2.6.11-rc2-mm1.

Thanks to Alex Nyberg and Zwane Mwaikambo for debugging help.
Cheers,
Con
This patch completes the implementation of the SCHED_ISO scheduling policy.

This splits the SCHED_ISO policy into two discrete policies which are the
unprivileged counterparts of SCHED_RR and SCHED_FIFO, calling them
SCHED_ISO_RR and SCHED_ISO_FIFO. When an unprivileged user calls for a real
time task they are downgraded to their SCHED_ISO counterparts.

This patch also adds full priority support to the isochronous scheduling
policies. Their range is the same size as the range available to
MAX_USER_RT_PRIO but their effective priority is lower than any privileged
real time tasks.

The priorities as seen to userspace would appear as:
0 -> 39  SCHED_NORMAL
-100 -> -1  Isochronous
-200 -> -101  Real time

Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>

Index: linux-2.6.11-rc2-mm1/include/linux/sched.h
===
--- linux-2.6.11-rc2-mm1.orig/include/linux/sched.h	2005-01-25 20:35:05.0 +1100
+++ linux-2.6.11-rc2-mm1/include/linux/sched.h	2005-01-25 20:36:01.0 +1100
@@ -132,18 +132,26 @@ extern unsigned long nr_iowait(void);
 #define SCHED_FIFO		1
 #define SCHED_RR		2
 /* policy 3 reserved for SCHED_BATCH */
-#define SCHED_ISO		4
+#define SCHED_ISO_RR		4
+#define SCHED_ISO_FIFO		5
 
 extern int iso_cpu, iso_period;
 
 #define SCHED_RANGE(policy)	((policy) == SCHED_NORMAL || \
 (policy) == SCHED_FIFO || \
 (policy) == SCHED_RR || \
-(policy) == SCHED_ISO)
+(policy) == SCHED_ISO_RR || \
+(policy) == SCHED_ISO_FIFO)
 
 #define SCHED_RT(policy)	((policy) == SCHED_FIFO || \
 (policy) == SCHED_RR)
 
+#define SCHED_ISO(policy)	((policy) == SCHED_ISO_RR || \
+(policy) == SCHED_ISO_FIFO)
+
+/* The policies that support a real time priority setting */
+#define SCHED_RT_PRIO(policy)	(SCHED_RT(policy) || SCHED_ISO(policy))
+
 struct sched_param {
 	int sched_priority;
 };
@@ -382,15 +390,21 @@ struct signal_struct {
  * user-space.  This allows kernel threads to set their
  * priority to a value higher than any user task. Note:
  * MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.
+ *
+ * SCHED_ISO tasks have a rt priority of the same range as
+ * real time tasks. They are seen as having either a priority
+ * of ISO_PRIO if below starvation limits or their underlying 
+ * equivalent SCHED_NORMAL priority if above.
  */
 
 #define MAX_USER_RT_PRIO	100
 #define MAX_RT_PRIO		MAX_USER_RT_PRIO
+#define ISO_PRIO		(MAX_RT_PRIO - 1)
 
 #define MAX_PRIO		(MAX_RT_PRIO + 40)
 
-#define rt_task(p)		(unlikely((p)->prio < MAX_RT_PRIO))
-#define iso_task(p)		(unlikely((p)->policy == SCHED_ISO))
+#define rt_task(p)		(unlikely((p)->prio < ISO_PRIO))
+#define iso_task(p)		(unlikely(SCHED_ISO((p)->policy)))
 
 /*
  * Some day this will be a full-fledged user tracking system..
Index: linux-2.6.11-rc2-mm1/kernel/sched.c
===
--- linux-2.6.11-rc2-mm1.orig/kernel/sched.c	2005-01-25 20:35:05.0 +1100
+++ linux-2.6.11-rc2-mm1/kernel/sched.c	2005-01-25 23:25:06.0 +1100
@@ -184,6 +184,8 @@ int iso_period = 5;	/* The time over whi
  */
 
 #define BITMAP_SIZE MAX_PRIO+1+7)/8)+sizeof(long)-1)/sizeof(long))
+#define ISO_BITMAP_SIZE MAX_USER_RT_PRIO+1+7)/8)+sizeof(long)-1)/ \
+			sizeof(long))
 
 typedef struct runqueue runqueue_t;
 
@@ -212,7 +214,9 @@ struct runqueue {
 	unsigned long cpu_load;
 #endif
 	unsigned long iso_ticks;
-	struct list_head iso_queue;
+	unsigned long iso_running;
+	unsigned long iso_bitmap[ISO_BITMAP_SIZE];
+	struct list_head iso_queue[MAX_USER_RT_PRIO];
 	int iso_refractory;
 	/*
 	 * Refractory is the flag that we've hit the maximum iso cpu and are
@@ -312,15 +316,26 @@ static DEFINE_PER_CPU(struct runqueue, r
 # define task_running(rq, p)		((rq)->curr == (p))
 #endif
 
-static inline int task_preempts_curr(task_t *p, runqueue_t *rq)
+static int task_preempts_curr(task_t *p, runqueue_t *rq)
 {
-	if ((!iso_task(p) && !iso_task(rq->curr)) || rq->iso_refractory ||
-		rt_task(p) || rt_task(rq->curr)) {
-			if (p->prio < rq->curr->prio)
-return 1;
-			return 0;
+	int p_prio = p->prio, curr_prio = rq->curr->prio;
+
+	if (!iso_task(p) && !iso_task(rq->curr))
+		goto out;
+	if (!rq->iso_refractory) {
+		if (iso_task(p)) {
+			if (iso_task(rq->curr)) {
+p_prio = -p->rt_priority;
+curr_prio = -rq->curr->rt_priority;
+goto out;
+			}
+			p_prio = ISO_PRIO;
+		if (iso_task(rq->curr))
+			curr_prio = ISO_PRIO;
+		}
 	}
-	if (iso_task(p) && !iso_task(rq->curr))
+out:
+	if (p_prio < curr_prio)
 		return 1;
 	return 0;
 }
@@ -590,41 +605,43 @@ static inline void sched_info_switc

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
There were numerous bugs in the SCHED_ISO design prior to now, so it 
really was not performing as expected. What is most interesting is that 
the DSP load goes to much higher levels now if xruns are avoided and 
stay at those high levels. If I push the cpu load too much so that they 
get transiently throttled from SCHED_ISO, after the Xrun the dsp load 
drops to half. Is this expected behaviour?

Anyway the next patch works well in my environment. Jack, while I 
realise you're getting the results you want from Ingo's dropped 
privilege, dropped cpu limit patch I would appreciate you testing this 
patch. It is not clear yet what direction we will take, but even if we 
dont do this, it would be nice just because of the effort on my part.

This version of the patch has full priority support and both ISO_RR and 
ISO_FIFO.

This is the patch to apply to 2.6.11-rc2-mm1:
http://ck.kolivas.org/patches/SCHED_ISO/2.6.11-rc2-mm1/2.6.11-rc2-mm1-iso-prio-fifo.diff 
Just for completeness, benchmarks:
logs and pretty pictures:
http://ck.kolivas.org/patches/SCHED_ISO/iso3-benchmarks/
SCHED_ISO:
Total seconds ran . . . . . . :   300
Number of clients . . . . . . :10
Ports per client  . . . . . . : 4
Frames per buffer . . . . . . :64
Number of runs  . . . . . . . :(3)
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 0
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :   150   usecs
Cycle Maximum . . . . . . . . :   725   usecs
Average DSP Load. . . . . . . :32.3 %
Average CPU System Load . . . : 6.0 %
Average CPU User Load . . . . :33.6 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.1 %
Average CPU IRQ Load  . . . . : 0.1 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1758.9 /sec
Average Context-Switch Rate . :  9208.7 /sec
and SCHED_ISO in the presence of continuous compile:
Total seconds ran . . . . . . :   300
Number of clients . . . . . . :10
Ports per client  . . . . . . : 4
Frames per buffer . . . . . . :64
Number of runs  . . . . . . . :(3)
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 0
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :   375   usecs
Cycle Maximum . . . . . . . . :   726   usecs
Average DSP Load. . . . . . . :35.8 %
Average CPU System Load . . . :15.1 %
Average CPU User Load . . . . :82.9 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 1.8 %
Average CPU IRQ Load  . . . . : 0.2 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1772.6 /sec
Average Context-Switch Rate . :  9565.2 /sec
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Con Kolivas]

Ingo Molnar wrote:
pretty much the only criticism of the RT-CPU patch was that the global
sysctl is too rigid and that it doesnt allow privileged tasks to ignore
the limit. I've uploaded a new RT-CPU-limit patch that solves this
problem:
  http://redhat.com/~mingo/rt-limit-patches/
i've removed the global sysctl and implemented a new rlimit,
RT_CPU_RATIO: the maximum amount of CPU time RT tasks may use, in
percent. For testing purposes it defaults to 80%.
the RT-limit being an rlimit makes it much more configurable: root tasks
can have unlimited CPU time limit, while users could have a more
conservative setting of say 30%. This also makes it per-process and
runtime configurable as well. The scheduler will instantly act upon any
new RT_CPU_RATIO rlimit.
(this approach is fundamentally different from the previous patch that
made the "maximum RT-priority available to an unprivileged task" value
an rlimit - with priorities being an rlimit we still havent made RT
priorities safe against deadlocks.)
multiple tasks can have different rlimits as well, and the scheduler
interprets it the following way: it maintains a per-CPU "RT CPU use"
load-average value and compares it against the per-task rlimit. If e.g. 
the task says "i'm in the 60% range" and the current average is 70%,
then the scheduler delays this RT task - if the next task has an 80%
rlimit then it will be allowed to run. This logic is straightforward and
can be used as a further control mechanism against runaway highprio RT
tasks.
Very nice. I like the way this approach is evolving.
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

2.6.11-rc2-mm1: freeing b_committed_data

[Con Kolivas]

Getting a few of these:
__journal_remove_journal_head: freeing b_committed_data
in my dmesg with this kernel. It's ext3 on a P-ATA drive.
Bad? Dangerous? harmless debugging stuff?
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

There were numerous bugs in the SCHED_ISO design prior to now, so it 
really was not performing as expected. What is most interesting is that 
the DSP load goes to much higher levels now if xruns are avoided and 
stay at those high levels. If I push the cpu load too much so that they 
get transiently throttled from SCHED_ISO, after the Xrun the dsp load 
drops to half. Is this expected behaviour?

Anyway the next patch works well in my environment. Jack, while I 
realise you're getting the results you want from Ingo's dropped 
privilege, dropped cpu limit patch I would appreciate you testing this 
patch. It is not clear yet what direction we will take, but even if we 
dont do this, it would be nice just because of the effort on my part.

This version of the patch has full priority support and both ISO_RR and 
ISO_FIFO.

This is the patch to apply to 2.6.11-rc2-mm1:
http://ck.kolivas.org/patches/SCHED_ISO/2.6.11-rc2-mm1/2.6.11-rc2-mm1-iso-prio-fifo.diff
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
-cc list trimmed to those who have recently responded.
Here is a patch to go on top of 2.6.11-rc2-mm1 that fixes some bugs in 
the general SCHED_ISO code, fixes the priority support between ISO 
threads, and implements SCHED_ISO_RR and SCHED_ISO_FIFO as separate 
policies. Note the bugfixes and cleanups mean the codepaths in this are 
leaner than the original ISO2 implementation despite the extra features.

This works safely and effectively on UP (but not tested on SMP yet) so 
Jack if/when you get a chance I'd love to see more benchmarks from you 
on this one. It seems on my machine the earlier ISO2 implementation 
without priority nor FIFO was enough for good results, but not on yours, 
which makes your testcase a more discriminating one.
Sorry, I see yet another flaw in the design and SMP is broken so hold 
off testing for a bit.

Cheers,
Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

-cc list trimmed to those who have recently responded.
Here is a patch to go on top of 2.6.11-rc2-mm1 that fixes some bugs in 
the general SCHED_ISO code, fixes the priority support between ISO 
threads, and implements SCHED_ISO_RR and SCHED_ISO_FIFO as separate 
policies. Note the bugfixes and cleanups mean the codepaths in this are 
leaner than the original ISO2 implementation despite the extra features.

This works safely and effectively on UP (but not tested on SMP yet) so 
Jack if/when you get a chance I'd love to see more benchmarks from you 
on this one. It seems on my machine the earlier ISO2 implementation 
without priority nor FIFO was enough for good results, but not on yours, 
which makes your testcase a more discriminating one.

Cheers,
Con
Index: linux-2.6.11-rc2-mm1/include/linux/sched.h
===
--- linux-2.6.11-rc2-mm1.orig/include/linux/sched.h	2005-01-25 08:50:33.0 +1100
+++ linux-2.6.11-rc2-mm1/include/linux/sched.h	2005-01-25 09:08:47.0 +1100
@@ -132,18 +132,26 @@ extern unsigned long nr_iowait(void);
 #define SCHED_FIFO		1
 #define SCHED_RR		2
 /* policy 3 reserved for SCHED_BATCH */
-#define SCHED_ISO		4
+#define SCHED_ISO_RR		4
+#define SCHED_ISO_FIFO		5
 
 extern int iso_cpu, iso_period;
 
 #define SCHED_RANGE(policy)	((policy) == SCHED_NORMAL || \
 (policy) == SCHED_FIFO || \
 (policy) == SCHED_RR || \
-(policy) == SCHED_ISO)
+(policy) == SCHED_ISO_RR || \
+(policy) == SCHED_ISO_FIFO)
 
 #define SCHED_RT(policy)	((policy) == SCHED_FIFO || \
 (policy) == SCHED_RR)
 
+#define SCHED_ISO(policy)	((policy) == SCHED_ISO_RR || \
+(policy) == SCHED_ISO_FIFO)
+
+/* The policies that support a real time priority setting */
+#define SCHED_RT_PRIO(policy)	(SCHED_RT(policy) || SCHED_ISO(policy))
+
 struct sched_param {
 	int sched_priority;
 };
@@ -382,15 +390,21 @@ struct signal_struct {
  * user-space.  This allows kernel threads to set their
  * priority to a value higher than any user task. Note:
  * MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.
+ *
+ * SCHED_ISO tasks have a rt priority of the same range as
+ * real time tasks. They are seen as having either a priority
+ * of ISO_PRIO if below starvation limits or their underlying 
+ * equivalent SCHED_NORMAL priority if above.
  */
 
 #define MAX_USER_RT_PRIO	100
 #define MAX_RT_PRIO		MAX_USER_RT_PRIO
+#define ISO_PRIO		(MAX_RT_PRIO - 1)
 
 #define MAX_PRIO		(MAX_RT_PRIO + 40)
 
-#define rt_task(p)		(unlikely((p)->prio < MAX_RT_PRIO))
-#define iso_task(p)		(unlikely((p)->policy == SCHED_ISO))
+#define rt_task(p)		(unlikely((p)->prio < ISO_PRIO))
+#define iso_task(p)		(unlikely(SCHED_ISO((p)->policy)))
 
 /*
  * Some day this will be a full-fledged user tracking system..
Index: linux-2.6.11-rc2-mm1/kernel/sched.c
===
--- linux-2.6.11-rc2-mm1.orig/kernel/sched.c	2005-01-25 08:50:33.0 +1100
+++ linux-2.6.11-rc2-mm1/kernel/sched.c	2005-01-25 09:07:02.0 +1100
@@ -184,6 +184,8 @@ int iso_period = 5;	/* The time over whi
  */
 
 #define BITMAP_SIZE MAX_PRIO+1+7)/8)+sizeof(long)-1)/sizeof(long))
+#define ISO_BITMAP_SIZE MAX_USER_RT_PRIO+1+7)/8)+sizeof(long)-1)/ \
+			sizeof(long))
 
 typedef struct runqueue runqueue_t;
 
@@ -212,7 +214,9 @@ struct runqueue {
 	unsigned long cpu_load;
 #endif
 	unsigned long iso_ticks;
-	struct list_head iso_queue;
+	unsigned int iso_active;
+	unsigned long iso_bitmap[ISO_BITMAP_SIZE];
+	struct list_head iso_queue[MAX_USER_RT_PRIO];
 	int iso_refractory;
 	/*
 	 * Refractory is the flag that we've hit the maximum iso cpu and are
@@ -312,15 +316,26 @@ static DEFINE_PER_CPU(struct runqueue, r
 # define task_running(rq, p)		((rq)->curr == (p))
 #endif
 
-static inline int task_preempts_curr(task_t *p, runqueue_t *rq)
+static int task_preempts_curr(task_t *p, runqueue_t *rq)
 {
-	if ((!iso_task(p) && !iso_task(rq->curr)) || rq->iso_refractory ||
-		rt_task(p) || rt_task(rq->curr)) {
-			if (p->prio < rq->curr->prio)
-return 1;
-			return 0;
+	int p_prio = p->prio, curr_prio = rq->curr->prio;
+
+	if (!iso_task(p) && !iso_task(rq->curr))
+		goto out;
+	if (!rq->iso_refractory) {
+		if (iso_task(p)) {
+			if (iso_task(rq->curr)) {
+p_prio = -p->rt_priority;
+curr_prio = -rq->curr->rt_priority;
+goto out;
+			}
+			p_prio = ISO_PRIO;
+		if (iso_task(rq->curr))
+			curr_prio = ISO_PRIO;
+		}
 	}
-	if (iso_task(p) && !iso_task(rq->curr))
+out:
+	if (p_prio < curr_prio)
 		return 1;
 	return 0;
 }
@@ -590,14 +605,13 @@ static inline void sched_info_switch(tas
 #define sched_info_switch(t, next)	do { } while (0)
 #endif /* CONFIG_SCHEDSTATS */
 
-static inline int iso_queued(runqueue_t *rq)
-{
-	return !list_empty(&rq->iso_queue);
-}
-
-static inline void dequeue_iso_task(struct task_struct *p)
+static void dequeue_iso_task(struct task_struct *p)
 {
+	runqueue_t *rq = task_rq(p);
+	rq->iso_active--;
 	list_del(&p

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
I still wonder if some coding error might occasionally be letting a
lower priority process continue running after an interrupt when it
ought to be preempted.
Well not surprisingly I did find a bug in my patch which did not honour 
priority support between ISO threads. So basically the patch only does 
as much as the original ISO patch. I'll slap something together for more 
testing with this fixed, and ISO_FIFO support too.

Cheers,
Con
-
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: [patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

[Con Kolivas]

Con Kolivas wrote:
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:

[...] "how do we give low latencies to audio applications (and other,
soft-RT alike applications), while not allowing them to lock up the
system."

ok, here is another approach, against 2.6.10/11-ish kernels:
  http://redhat.com/~mingo/rt-limit-patches/
this patch adds the /proc/sys/kernel/rt_cpu_limit tunable: the maximum
amount of CPU time all RT tasks combined may use, in percent. Defaults
to 80%.
just apply the patch to 2.6.11-rc2 and you should be able to run e.g. 
"jackd -R" as an unprivileged user.

note that this allows the use of SCHED_FIFO/SCHED_RR policies, without
the need to add any new scheduling classes. The RT CPU-limit acts on the
existing RT-scheduling classes, by adding a pretty simple and
straightforward method of tracking their CPU usage, and limiting them if
they exceed the threshold. As long as the treshold is not violated the
scheduling/latency properties of those scheduling classes remains.
It would be very interesting to see how jackd/jack_test performs with
this patch applied, and rt_cpu_limit is set to different percentages,
compared against unpatched SCHED_FIFO performance.

Indeed it would be interesting because assuming there are no bugs in my 
SCHED_ISO implementation (which is unlikely) it should perform the same.

There are a number of features that it would be nice to have addressed 
if we take this route.

Superusers are unable to set anything higher priority than unprivileged 
users. Any restrictions placed on SCHED_RR/FIFO for unprivileged users 
affect superuser tasks as well. The default setting breaks the 
definition of these policies, yet changing the setting to 100 gives 
everyone full rt access.

ie it would be nice for there to be discrepancy between the default cpu 
limits and priority levels available to unprivileged vs superusers, and 
superusers' default settings to remain the same as current SCHED_RR/FIFO 
behaviour.
I guess it would be a simple matter of throwing on another 100 rt 
priorities that can only be set by CAP_SYS_NICE, and limiting 
selectively based on the rt_priority.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

[Con Kolivas]

Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:

[...] "how do we give low latencies to audio applications (and other,
soft-RT alike applications), while not allowing them to lock up the
system."

ok, here is another approach, against 2.6.10/11-ish kernels:
  http://redhat.com/~mingo/rt-limit-patches/
this patch adds the /proc/sys/kernel/rt_cpu_limit tunable: the maximum
amount of CPU time all RT tasks combined may use, in percent. Defaults
to 80%.
just apply the patch to 2.6.11-rc2 and you should be able to run e.g. 
"jackd -R" as an unprivileged user.

note that this allows the use of SCHED_FIFO/SCHED_RR policies, without
the need to add any new scheduling classes. The RT CPU-limit acts on the
existing RT-scheduling classes, by adding a pretty simple and
straightforward method of tracking their CPU usage, and limiting them if
they exceed the threshold. As long as the treshold is not violated the
scheduling/latency properties of those scheduling classes remains.
It would be very interesting to see how jackd/jack_test performs with
this patch applied, and rt_cpu_limit is set to different percentages,
compared against unpatched SCHED_FIFO performance.
Indeed it would be interesting because assuming there are no bugs in my 
SCHED_ISO implementation (which is unlikely) it should perform the same.

There are a number of features that it would be nice to have addressed 
if we take this route.

Superusers are unable to set anything higher priority than unprivileged 
users. Any restrictions placed on SCHED_RR/FIFO for unprivileged users 
affect superuser tasks as well. The default setting breaks the 
definition of these policies, yet changing the setting to 100 gives 
everyone full rt access.

ie it would be nice for there to be discrepancy between the default cpu 
limits and priority levels available to unprivileged vs superusers, and 
superusers' default settings to remain the same as current SCHED_RR/FIFO 
behaviour.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
I'll try building a SCHED_RR version of JACK.  I still don't think it
will make any difference.  But my intuition isn't working very well
right now, so I need more data.
Could be that despite what it appears, FIFO behaviour may be desirable 
to RR. Also the RR in SCHED_ISO is pretty fast at 10ms. However with 
nothing else really running it just shouldn't matter...

I still wonder if some coding error might occasionally be letting a
lower priority process continue running after an interrupt when it
ought to be preempted.
That's one distinct possiblity. Preempt code is a particular problem.
You are not running into the cpu limits of SCHED_ISO so something else 
must be responsible. If we are higher priority than everything else and 
do no expire in any way there is no reason we shouldn't perform as well 
as SCHED_FIFO.

There is some sort of privileged memory handling when jackd is running 
as root as well, so I don't know how that features here. I can't imagine 
it's a real issue though.

Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

There are two things that the SCHED_ISO you tried is not that
SCHED_FIFO is - As you mentioned there is no priority support, and it
is RR, not FIFO. I am not sure whether it is one and or the other
responsible. Both can be added to SCHED_ISO. I haven't looked at jackd
code but it should be trivial to change SCHED_FIFO to SCHED_RR to see
if RR with priority support is enough or not. 

Sure, that's easy.  I didn't do it because I assumed it would not
matter.  Since the RR scheduling quantum is considerably longer than
the basic 1.45msec audio cycle, it should work exactly the same.  I'll
cobble together a JACK version to try that for you.
If you already know the audio cycle is much less than 10ms then there 
isn't much point trying it.

Second the patch I sent you is fine for testing; I was hoping you
would try it. What you can't do with it is spawn lots of userspace
apps safely SCHED_ISO with it - it will crash, but it not take down
your hard disk. I've had significantly better results with that
patch so far. Then we cn take it from there.

Sorry.  I took you literally when you said it was not yet ready to
try.  This would be the isoprio3 patch you posted?
Yes it is.
Do I have to use 2.6.11-rc1-mm2, or will it work with 2.6.11-rc1?
It was for mm2, but should patch on an iso2 patched kernel.
Thanks!
Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Looked at this way, there really is no question.  The new scheduler
prototypes are falling short significantly.  Could this be due to
their lack of priority distinctions between realtime threads?  Maybe.
I can't say for sure.  I'll be interested to see what happens when Con
is ready for me to try his new priority-based SCHED_ISO prototype.
There are two things that the SCHED_ISO you tried is not that SCHED_FIFO 
is - As you mentioned there is no priority support, and it is RR, not 
FIFO. I am not sure whether it is one and or the other responsible. Both 
can be added to SCHED_ISO. I haven't looked at jackd code but it should 
be trivial to change SCHED_FIFO to SCHED_RR to see if RR with priority 
support is enough or not. Second the patch I sent you is fine for 
testing; I was hoping you would try it. What you can't do with it is 
spawn lots of userspace apps safely SCHED_ISO with it - it will crash, 
but it not take down your hard disk. I've had significantly better 
results with that patch so far. Then we cn take it from there.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
I'm wondering now if the lack of priority support in the two
prototypes might explain the problems I'm seeing.
Distinctly possible since my results got better with priority support. 
However I'm still bugfixing what I've got. Just as a data point here is 
an incremental patch for testing which applies to mm2. This survives
a jackd test run at my end but is not ready for inclusion yet.

Cheers,
Con
Index: linux-2.6.11-rc1-mm2/include/linux/sched.h
===
--- linux-2.6.11-rc1-mm2.orig/include/linux/sched.h	2005-01-22 20:42:44.0 +1100
+++ linux-2.6.11-rc1-mm2/include/linux/sched.h	2005-01-22 20:50:29.0 +1100
@@ -144,6 +144,10 @@ extern int iso_cpu, iso_period;
 #define SCHED_RT(policy)	((policy) == SCHED_FIFO || \
 (policy) == SCHED_RR)
 
+/* The policies that support a real time priority setting */
+#define SCHED_RT_PRIO(policy)	(SCHED_RT(policy) || \
+(policy) == SCHED_ISO)
+
 struct sched_param {
 	int sched_priority;
 };
@@ -356,7 +360,7 @@ struct signal_struct {
 /*
  * Priority of a process goes from 0..MAX_PRIO-1, valid RT
  * priority is 0..MAX_RT_PRIO-1, and SCHED_NORMAL tasks are
- * in the range MAX_RT_PRIO..MAX_PRIO-1. Priority values
+ * in the range MIN_NORMAL_PRIO..MAX_PRIO-1. Priority values
  * are inverted: lower p->prio value means higher priority.
  *
  * The MAX_USER_RT_PRIO value allows the actual maximum
@@ -364,12 +368,19 @@ struct signal_struct {
  * user-space.  This allows kernel threads to set their
  * priority to a value higher than any user task. Note:
  * MAX_RT_PRIO must not be smaller than MAX_USER_RT_PRIO.
+ *
+ * SCHED_ISO tasks have a rt priority of the same range as
+ * real time tasks. They are seen as having either a priority
+ * of ISO_PRIO if below starvation limits or their underlying 
+ * equivalent SCHED_NORMAL priority if above.
  */
 
 #define MAX_USER_RT_PRIO	100
 #define MAX_RT_PRIO		MAX_USER_RT_PRIO
+#define ISO_PRIO		MAX_RT_PRIO
+#define MIN_NORMAL_PRIO		(ISO_PRIO + 1)
 
-#define MAX_PRIO		(MAX_RT_PRIO + 40)
+#define MAX_PRIO		(MIN_NORMAL_PRIO + 40)
 
 #define rt_task(p)		(unlikely((p)->prio < MAX_RT_PRIO))
 #define iso_task(p)		(unlikely((p)->policy == SCHED_ISO))
Index: linux-2.6.11-rc1-mm2/kernel/sched.c
===
--- linux-2.6.11-rc1-mm2.orig/kernel/sched.c	2005-01-22 09:19:42.0 +1100
+++ linux-2.6.11-rc1-mm2/kernel/sched.c	2005-01-23 17:38:27.848054361 +1100
@@ -55,11 +55,11 @@
 
 /*
  * Convert user-nice values [ -20 ... 0 ... 19 ]
- * to static priority [ MAX_RT_PRIO..MAX_PRIO-1 ],
+ * to static priority [ MIN_NORMAL_PRIO..MAX_PRIO-1 ],
  * and back.
  */
-#define NICE_TO_PRIO(nice)	(MAX_RT_PRIO + (nice) + 20)
-#define PRIO_TO_NICE(prio)	((prio) - MAX_RT_PRIO - 20)
+#define NICE_TO_PRIO(nice)	(MIN_NORMAL_PRIO + (nice) + 20)
+#define PRIO_TO_NICE(prio)	((prio) - MIN_NORMAL_PRIO - 20)
 #define TASK_NICE(p)		PRIO_TO_NICE((p)->static_prio)
 
 /*
@@ -67,7 +67,7 @@
  * can work with better when scaling various scheduler parameters,
  * it's a [ 0 ... 39 ] range.
  */
-#define USER_PRIO(p)		((p)-MAX_RT_PRIO)
+#define USER_PRIO(p)		((p)-MIN_NORMAL_PRIO)
 #define TASK_USER_PRIO(p)	USER_PRIO((p)->static_prio)
 #define MAX_USER_PRIO		(USER_PRIO(MAX_PRIO))
 
@@ -184,6 +184,8 @@ int iso_period = 5;	/* The time over whi
  */
 
 #define BITMAP_SIZE MAX_PRIO+1+7)/8)+sizeof(long)-1)/sizeof(long))
+#define ISO_BITMAP_SIZE MAX_USER_RT_PRIO+1+7)/8)+sizeof(long)-1)/ \
+			sizeof(long))
 
 typedef struct runqueue runqueue_t;
 
@@ -212,7 +214,9 @@ struct runqueue {
 	unsigned long cpu_load;
 #endif
 	unsigned long iso_ticks;
-	struct list_head iso_queue;
+	unsigned int iso_active;
+	unsigned long iso_bitmap[ISO_BITMAP_SIZE];
+	struct list_head iso_queue[MAX_USER_RT_PRIO];
 	int iso_refractory;
 	/*
 	 * Refractory is the flag that we've hit the maximum iso cpu and are
@@ -312,15 +316,20 @@ static DEFINE_PER_CPU(struct runqueue, r
 # define task_running(rq, p)		((rq)->curr == (p))
 #endif
 
-static inline int task_preempts_curr(task_t *p, runqueue_t *rq)
+static int task_preempts_curr(task_t *p, runqueue_t *rq)
 {
-	if ((!iso_task(p) && !iso_task(rq->curr)) || rq->iso_refractory ||
-		rt_task(p) || rt_task(rq->curr)) {
-			if (p->prio < rq->curr->prio)
-return 1;
-			return 0;
+	int p_prio = p->prio, curr_prio = rq->curr->prio;
+
+	if (!iso_task(p) && !iso_task(rq->curr))
+		goto check_preemption;
+	if (!rq->iso_refractory) {
+		if (iso_task(p))
+			p_prio = ISO_PRIO;
+		if (iso_task(rq->curr))
+			curr_prio = ISO_PRIO;
 	}
-	if (iso_task(p) && !iso_task(rq->curr))
+check_preemption:
+	if (p_prio < curr_prio)
 		return 1;
 	return 0;
 }
@@ -590,14 +599,13 @@ static inline void sched_info_switch(tas
 #define sched_info_switch(t, next)	do { } while (0)
 #endif /* CONFIG_SCHEDSTATS */
 
-static inline int iso_queued(runqueue_t *rq)
-{
-	return !list_empty(&rq->iso_queue);
-}
-
-static inline void deq

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Jack O'Quin wrote:
[snip lots of valid points]
suggest some things to try.  First, make sure the JACK tmp directory
is mounted on a tmpfs[1].  Then, try the test with ext2, instead of
Looks like the tmpfs is probably the biggest problem. Here's SCHED_ISO
with just the /tmp mounted on tmpfs change - running on a complete
desktop environment with a 2nd exported X seession and my wife
browsing the net and emailing at the same time.
All invalid runs removed and just this one posted here:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/
How's that look?

Excellent!  

Sorry I didn't warn you about that problem before.  JACK audio users
generally know about it, but there's no reason you should have.
So, that was run with ext3?
Yes I think I mentioned before this is a different machine than the 
pentiumM one. It's a P4HT3.06 with on board i810 sound and ext3 (which 
explains the vastly different DSP usage). The only "special" measure 
taken for jackd was to use the latest jackd code and the tmpfs mount you 
suggested. Looks like the number of steps to convert a modern "standard 
setup" desktop to a low latency one on linux aren't that big after all :)

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
[snip lots of valid points]
suggest some things to try.  First, make sure the JACK tmp directory
is mounted on a tmpfs[1].  Then, try the test with ext2, instead of
Looks like the tmpfs is probably the biggest problem. Here's SCHED_ISO 
with just the /tmp mounted on tmpfs change - running on a complete 
desktop environment with a 2nd exported X seession and my wife browsing 
the net and emailing at the same time.

* SUMMARY RESULT 
Total seconds ran . . . . . . :   300
Number of clients . . . . . . :14
Ports per client  . . . . . . : 4
Frames per buffer . . . . . . :64
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 0
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :72   usecs
Cycle Maximum . . . . . . . . :  1108   usecs
Average DSP Load. . . . . . . :50.1 %
Average CPU System Load . . . :10.7 %
Average CPU User Load . . . . :18.3 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.1 %
Average CPU IRQ Load  . . . . : 0.0 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1693.1 /sec
Average Context-Switch Rate . : 18852.7 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
Warning: empty y2 range [0:0], adjusting to [0:1]
All invalid runs removed and just this one posted here:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/
How's that look?
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: Supermount / ivman

[Con Kolivas]

Gustavo Guillermo Perez wrote:
Cause I play with old toys, (floppys) and ivman doesn't work properly on the 
lastest gentoo with floppys, I retouch for a while the supermount patch from 
sourceforge for kernel 2.6.11-rc1.

I'm a n00b on kernel, I do this only for general purposes helping some 
friends, I know supermount should not be used, and is not mantained, I've 
tested it just only for IDE/ATAPI CD/DVD and floppys.

Cause Supermount seems to be a filesystem I replace vfs_permission by 
generic_permission instead of permission as I read on the lkml. Other stuffs 
too in scsi section (I don't have scsi hardware).

If Help someone else:
http://www.compunauta.com/forums/linux/instalarlinux/supermount_en.html
I've been silently maintaining it offlist. No real development but 
keeping it in sync and fixing obvious bugs that show up that I can fix.

Here's a patch for 2.6.10-ck5 (should apply fairly cleanly to 2.6.10):
http://ck.kolivas.org/patches/2.6/2.6.10/2.6.10-ck5/patches/supermount-ng208-10ck5.diff
and for 2.6.11-rc1
http://ck.kolivas.org/patches/2.6/2.6.11-rc1/patches/supermount-ng208-2611rc1.diff
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Paul Davis wrote:
The idea is to get equivalent performance to SCHED_FIFO. The results 
show that much, and it is 100 times better than unprivileged 
SCHED_NORMAL. The fact that this is an unoptimised normal desktop 
environment means that the conclusion we _can_ draw is that SCHED_ISO is 
as good as SCHED_FIFO for audio on the average desktop. I need someone 

no, this isn't true. the performance you are getting isn't as good as
SCHED_FIFO on a tuned system (h/w and s/w). the difference might be
the fact that you have "an average desktop", or it might be that your
desktop is just fine and SCHED_ISO actually is not as good as
SCHED_FIFO. 

On my desktop, whatever that is, SCHED_FIFO and SCHED_ISO results were 
the same.



with optimised hardware setup to see if it's as good as SCHED_FIFO in 
the critical setup.

agreed. i have every confidence that Lee and/or Jack will be
forthcoming :)
Good stuff :).
Meanwhile, I have the priority support working (but not bug free), and 
the preliminary results suggest that the results are better. Do I recall 
someone mentioning jackd uses threads at different priority?

Cheers,
Con
P.S. If you read any emotion in my emails without a smiley or frowny 
face it's unintentional and is the limited emotional range the email 
format is allowed to convey. Hmm.. perhaps I should make this my sig ;)


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Neither run exhibits reliable audio performance.  There is some low
latency performance problem with your system.  Maybe ReiserFS is
causing trouble even with logging turned off.  Perhaps the problem is
somewhere else.  Maybe some device is misbehaving.
Until you solve this problem, beware of drawing conclusions.
The idea is to get equivalent performance to SCHED_FIFO. The results 
show that much, and it is 100 times better than unprivileged 
SCHED_NORMAL. The fact that this is an unoptimised normal desktop 
environment means that the conclusion we _can_ draw is that SCHED_ISO is 
as good as SCHED_FIFO for audio on the average desktop. I need someone 
with optimised hardware setup to see if it's as good as SCHED_FIFO in 
the critical setup.

I'm actually not an audio person and have no need for such a setup, but 
I can see how linux would benefit from such support... ;)

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

So let's try again, sorry about the noise:
==> jack_test4-2.6.11-rc1-mm2-fifo.log <==
*
XRUN Count  . . . . . . . . . : 3
Delay Maximum . . . . . . . . : 20161   usecs
*
==> jack_test4-2.6.11-rc1-mm2-iso.log <==
*
XRUN Count  . . . . . . . . . : 6
Delay Maximum . . . . . . . . :  4604   usecs
*
Pretty pictures:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/

Neither run exhibits reliable audio performance.  There is some low
latency performance problem with your system.  Maybe ReiserFS is
causing trouble even with logging turned off.  Perhaps the problem is
somewhere else.  Maybe some device is misbehaving.
Until you solve this problem, beware of drawing conclusions.
Sigh.. I guess you want me to do all the benchmarking. Well it's easy 
enough to get good results. I'll simply turn off all services and not 
run a desktop. This is all on ext3 on a fully laden desktop by the way, 
but if you want to get the results you're looking for I can easily drop 
down to a console and get perfect results.

Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
Con Kolivas wrote:
Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Here's fresh results on more stressed hardware (on ext3) with
2.6.11-rc1-mm2 (which by the way has SCHED_ISO v2 included). The load
hovering at 50% spikes at times close to 70 which tests the behaviour
under iso throttling.


What version of JACK are you running (`jackd --version')?
You're still getting zero Delay Max.  That is an important measure.
Ok updated jackd
So let's try again, sorry about the noise:
==> jack_test4-2.6.11-rc1-mm2-fifo.log <==
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 3
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 20161   usecs
Cycle Maximum . . . . . . . . :  1072   usecs
Average DSP Load. . . . . . . :47.2 %
Average CPU System Load . . . : 5.1 %
Average CPU User Load . . . . :18.0 %
Average CPU Nice Load . . . . : 0.1 %
Average CPU I/O Wait Load . . : 0.3 %
Average CPU IRQ Load  . . . . : 0.0 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1701.6 /sec
Average Context-Switch Rate . : 19343.7 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
==> jack_test4-2.6.11-rc1-mm2-iso.log <==
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 6
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  4604   usecs
Cycle Maximum . . . . . . . . :  1190   usecs
Average DSP Load. . . . . . . :54.5 %
Average CPU System Load . . . :11.6 %
Average CPU User Load . . . . :18.4 %
Average CPU Nice Load . . . . : 0.1 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.0 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1697.9 /sec
Average Context-Switch Rate . : 19046.2 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
Pretty pictures:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/
Note these are on a full desktop environment, although it is pretty much 
idle apart from checking email. No changes between fifo and iso runs.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Here's fresh results on more stressed hardware (on ext3) with
2.6.11-rc1-mm2 (which by the way has SCHED_ISO v2 included). The load
hovering at 50% spikes at times close to 70 which tests the behaviour
under iso throttling.

What version of JACK are you running (`jackd --version')?
You're still getting zero Delay Max.  That is an important measure.

Ok updated jackd
Here's an updated set of runs. Not very impressive even with SCHED_FIFO, 
but the same from both policies.

==> jack_test4-2.6.11-rc1-mm2-fifo.log <==
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :   404
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 261254   usecs
Cycle Maximum . . . . . . . . :  2701   usecs
Average DSP Load. . . . . . . :52.4 %
Average CPU System Load . . . : 5.1 %
Average CPU User Load . . . . :18.1 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.0 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1699.3 /sec
Average Context-Switch Rate . : 19018.9 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
==> jack_test4-2.6.11-rc1-mm2-iso.log <==
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :   408
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 269804   usecs
Cycle Maximum . . . . . . . . :  2449   usecs
Average DSP Load. . . . . . . :52.6 %
Average CPU System Load . . . : 5.0 %
Average CPU User Load . . . . :17.8 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.1 %
Average CPU IRQ Load  . . . . : 0.0 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1699.2 /sec
Average Context-Switch Rate . : 19041.0 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
Bah stupid me. Both of those are SCHED_NORMAL.
Ignore those, and I'll try again.
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Here's fresh results on more stressed hardware (on ext3) with
2.6.11-rc1-mm2 (which by the way has SCHED_ISO v2 included). The load
hovering at 50% spikes at times close to 70 which tests the behaviour
under iso throttling.

What version of JACK are you running (`jackd --version')?
You're still getting zero Delay Max.  That is an important measure.
Ok updated jackd
Here's an updated set of runs. Not very impressive even with SCHED_FIFO, 
but the same from both policies.

==> jack_test4-2.6.11-rc1-mm2-fifo.log <==
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :   404
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 261254   usecs
Cycle Maximum . . . . . . . . :  2701   usecs
Average DSP Load. . . . . . . :52.4 %
Average CPU System Load . . . : 5.1 %
Average CPU User Load . . . . :18.1 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.0 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1699.3 /sec
Average Context-Switch Rate . : 19018.9 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
==> jack_test4-2.6.11-rc1-mm2-iso.log <==
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :   408
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 269804   usecs
Cycle Maximum . . . . . . . . :  2449   usecs
Average DSP Load. . . . . . . :52.6 %
Average CPU System Load . . . : 5.0 %
Average CPU User Load . . . . :17.8 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.1 %
Average CPU IRQ Load  . . . . : 0.0 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1699.2 /sec
Average Context-Switch Rate . : 19041.0 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
I've updated the pretty graphs and removed the dud runs from here:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Here's fresh results on more stressed hardware (on ext3) with
2.6.11-rc1-mm2 (which by the way has SCHED_ISO v2 included). The load
hovering at 50% spikes at times close to 70 which tests the behaviour
under iso throttling.

What version of JACK are you running (`jackd --version')?
You're still getting zero Delay Max.  That is an important measure.
Oops I haven't updated it on this machine.
jackd version 0.99.0 tmpdir /tmp protocol 13
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

utz lehmann wrote:
On Sat, 2005-01-22 at 10:48 +1100, Con Kolivas wrote:
utz lehmann wrote:
Hi
I dislike the behavior of the SCHED_ISO patch that iso tasks are
degraded to SCHED_NORMAL if they exceed the limit.
IMHO it's better to throttle them at the iso_cpu limit.
I have modified Con's iso2 patch to do this. If iso_cpu > 50 iso tasks
only get stalled for 1 tick (1ms on x86).
Some tasks are so cache intensive they would make almost no forward 
progress running for only 1ms.

Ok. The throttle duration can be exceed.
What is a good value? 5ms, 10ms?
It's architecture and cpu dependant. Useful timeslices to avoid cache 
trashing vary from 2ms to 20ms. Also HZ varies between architectures and 
setups, and almost certainly will vary in some dynamic way in the future 
altering substantially the accuracy of such a setup.

Fortunately there is a currently unused task prio (MAX_RT_PRIO-1) [1]. I
Your implementation is not correct. The "prio" field of real time tasks 
is determined by MAX_RT_PRIO-1-rt_priority. Therefore you're limiting 
the best real time priority, not the other way around.

Really? The task prios are (lower value is higher priority):
0
..  For SCHED_FIFO/SCHED_RR (rt_priority 99..1)
98  MAX_RT_PRIO-2
99  MAX_RT_PRIO-1   ISO_PRIO (rt_priority 0)
100 MAX_RT_PRIO
..  For SCHED_NORMAL
139 MAX_PRIO-1
ISO_PRIO is between the SCHED_FIFO/SCHED_RR and the SCHED_NORMAL range.
I wan't debating that fact. I was saying that decreasing the range of 
priorities you can have for real time will lose the highest priority ones.

if (SCHED_RT(policy))
p->prio = MAX_USER_RT_PRIO-1 - p->rt_priority;
Throttling them for only 1ms will make it very easy to starve the system 
 with 1 or more short running (<1ms) SCHED_NORMAL tasks running. Lower 
priority tasks will never run.
can I also comment on:
+   while (!list_empty(queue)) {
+   next = list_entry(queue->next, task_t, run_list);
+   dequeue_task(next, active);
+   enqueue_task(next, expired);
+   }
O(n) functions are a bad idea in critical codepaths, even if they only 
get hit when there is more than one SCHED_ISO task queued.

Apart from those, I'm not really sure what advantage this different 
design has. Once you go over the cpu limit the behaviour is grey and 
your design basically complicates what is already simple - to make an 
unprivileged task starvation free you run it SCHED_NORMAL. I know you 
want it back to high priority as soon as possible, but I fail to see how 
this is any better. They're either real time or not depending on what 
limits you set in either design.

As for priority support, I have been working on it. While the test cases 
I've been involved in show no need for it, I can understand why it would 
be desirable.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Rui Nuno Capela wrote:
OK. Here goes my fresh and newly jack_test4.1 test suite. It might be
still rough, as usual ;)
Thanks
Here's fresh results on more stressed hardware (on ext3) with 
2.6.11-rc1-mm2 (which by the way has SCHED_ISO v2 included). The load 
hovering at 50% spikes at times close to 70 which tests the behaviour 
under iso throttling.

==> jack_test4-2.6.11-rc1-mm2-fifo.log <==
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :41
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 0   usecs
Cycle Maximum . . . . . . . . : 10968   usecs
Average DSP Load. . . . . . . :44.3 %
Average CPU System Load . . . : 4.9 %
Average CPU User Load . . . . :17.1 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.0 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1689.9 /sec
Average Context-Switch Rate . : 19052.6 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
==> jack_test4-2.6.11-rc1-mm2-iso.log <==
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 2
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 0   usecs
Cycle Maximum . . . . . . . . :  1282   usecs
Average DSP Load. . . . . . . :50.5 %
Average CPU System Load . . . :11.2 %
Average CPU User Load . . . . :17.6 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.0 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1688.8 /sec
Average Context-Switch Rate . : 18985.1 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
==> jack_test4-2.6.11-rc1-mm2-normal.log <==
Number of runs  . . . . . . . :(1)
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :   325
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 0   usecs
Cycle Maximum . . . . . . . . :  4726   usecs
Average DSP Load. . . . . . . :50.0 %
Average CPU System Load . . . : 5.1 %
Average CPU User Load . . . . :18.7 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.1 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1704.5 /sec
Average Context-Switch Rate . : 18875.2 /sec
*
Delta Maximum . . . . . . . . : 0.0
*
Full data and pretty pictures:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

utz lehmann wrote:
Hi
I dislike the behavior of the SCHED_ISO patch that iso tasks are
degraded to SCHED_NORMAL if they exceed the limit.
IMHO it's better to throttle them at the iso_cpu limit.
I have modified Con's iso2 patch to do this. If iso_cpu > 50 iso tasks
only get stalled for 1 tick (1ms on x86).
Some tasks are so cache intensive they would make almost no forward 
progress running for only 1ms.

Fortunately there is a currently unused task prio (MAX_RT_PRIO-1) [1]. I
Your implementation is not correct. The "prio" field of real time tasks 
is determined by MAX_RT_PRIO-1-rt_priority. Therefore you're limiting 
the best real time priority, not the other way around.

Throttling them for only 1ms will make it very easy to starve the system 
 with 1 or more short running (<1ms) SCHED_NORMAL tasks running. Lower 
priority tasks will never run.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

[PATCH] sched: account rt_tasks as iso_ticks

[Con Kolivas]

SCHED_ISO tasks should have their cpu accounting be a proportion of 
ticks that would normally be available for SCHED_NORMAL tasks.

Add ticks consumed by rt_tasks to the iso_ticks variable and comments.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc1-mm2/kernel/sched.c
===
--- linux-2.6.11-rc1-mm2.orig/kernel/sched.c	2005-01-22 09:36:27.0 +1100
+++ linux-2.6.11-rc1-mm2/kernel/sched.c	2005-01-22 09:36:49.0 +1100
@@ -2499,7 +2499,13 @@ void scheduler_tick(void)
 	task_t *p = current;
 
 	rq->timestamp_last_tick = sched_clock();
-	if (iso_task(p) && !rq->iso_refractory)
+	/*
+	 * The iso_ticks accounting is incremented only when a SCHED_ISO task
+	 * is running in soft rt mode. Running rt_tasks are also accounted
+	 * to make the iso_cpu a proportion of cpu available for SCHED_NORMAL
+	 * tasks only.
+	 */
+	if (rt_task(p) || (iso_task(p) && !rq->iso_refractory))
 		inc_iso_ticks(rq, p);
 	else
 		dec_iso_ticks(rq, p);


signature.asc
Description: OpenPGP digital signature

Re: 2.6.11-rc1-mm2

[Con Kolivas]

Adrian Bunk wrote:
On Fri, Jan 21, 2005 at 07:06:31PM +1100, Con Kolivas wrote:
Wont boot.
Stops after BIOS check successful.
Tried reverting a couple of patches mentioning boot or reboot and had no 
luck. Any ideas?
...

Known bug that came from Linus' tree, already fixed in Linus' tree.
The thread discussion this bug starts with
  http://www.ussg.iu.edu/hypermail/linux/kernel/0501.2/1132.html
Yes indeed that fixes it. Thanks!
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCE][RFC] plugsched-2.0 patches ...

[Con Kolivas]

Marc E. Fiuczynski wrote:
Paraphrasing Jens Axboe:
I don't think you can compare [plugsched with the plugio framework].
Yes they are both schedulers, but that's about where the 'similarity'
stops. The CPU scheduler must be really fast, overhead must be kept
to a minimum. For a disk scheduler, we can affort to burn cpu cycles
to increase the io performance. The extra abstraction required to
fully modularize the cpu scheduler would come at a non-zero cost as
well, but I bet it would have a larger impact there. I doubt you
could measure the difference in the disk scheduler.

Modularization usually is done through a level of indirection (function
pointers).  I have a can of "indirection be gone" almost ready to spray over
the plugsched framework that would reduce the overhead to zero at runtime.
I'd be happy to finish that work if it makes it more palpable to integrate a
plugsched framework into the kernel?
The indirection was a minor point. On modern cpus it was suggested by 
wli that this would not be a demonstrable hit in perormance. Having said 
that, I'm sure Peter would be happy for another developer. I know how 
tiring and lonely it can feel maintaining such a monster.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Rui Nuno Capela wrote:
Jack O'Quin wrote:
[...] Looking at the graph, it appears that your DSP load is hovering
above 70% most of the time.  This happens to be the default threshold
for revoking realtime privileges.  Perhaps that is the problem.  Try
running it with the threshold set to 90%.  (I don't recall exactly
how, but I think there's a /proc/sys/kernel control somewhere.)

It would be nice to know which one really is :) Here are what I have here:
# grep . /proc/sys/kernel
/proc/sys/kernel/bootloader_type:2
/proc/sys/kernel/cad_pid:1
/proc/sys/kernel/cap-bound:-257
/proc/sys/kernel/core_pattern:core
/proc/sys/kernel/core_uses_pid:1
/proc/sys/kernel/ctrl-alt-del:0
/proc/sys/kernel/debug_direct_keyboard:0
/proc/sys/kernel/domainname:(none)
/proc/sys/kernel/hostname:lambda
/proc/sys/kernel/hotplug:/sbin/hotplug
/proc/sys/kernel/kernel_preemption:1
/proc/sys/kernel/modprobe:/sbin/modprobe
/proc/sys/kernel/msgmax:8192
/proc/sys/kernel/msgmnb:16384
/proc/sys/kernel/msgmni:16
/proc/sys/kernel/ngroups_max:65536
/proc/sys/kernel/osrelease:2.6.11-rc1-RT-V0.7.35-01.0
/proc/sys/kernel/ostype:Linux
/proc/sys/kernel/overflowgid:65534
/proc/sys/kernel/overflowuid:65534
/proc/sys/kernel/panic:0
/proc/sys/kernel/panic_on_oops:0
/proc/sys/kernel/pid_max:32768
/proc/sys/kernel/printk:3   4   1   7
/proc/sys/kernel/printk_ratelimit:5
/proc/sys/kernel/printk_ratelimit_burst:10
/proc/sys/kernel/prof_pid:-1
/proc/sys/kernel/sem:25032000   32  128
/proc/sys/kernel/shmall:2097152
/proc/sys/kernel/shmmax:33554432
/proc/sys/kernel/shmmni:4096
/proc/sys/kernel/sysrq:1
/proc/sys/kernel/tainted:0
/proc/sys/kernel/threads-max:8055
/proc/sys/kernel/unknown_nmi_panic:0
/proc/sys/kernel/version:#1 Mon Jan 17 15:15:21 WET 2005
My eyes can't find anything related, but you know how intuitive these
things are ;)
He means when using the SCHED_ISO patch. Then you'd have iso_cpu and 
iso_period, which you have neither of so you are not using SCHED_ISO.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: 2.6.11-rc1-mm2

[Con Kolivas]

Andrew Morton wrote:
Con Kolivas <[EMAIL PROTECTED]> wrote:
Stops after BIOS check successful.
earlyprintk on

What does this mean, btw?  Can you be more specific about where it gets
stuck?
It says decompressing BIOS check successful and then sits there
If you mean that it actually prints no messages at all then yeah, early
printk.  One suspect would be the kexec patches which play with boot-time
memory layouts and such.
Hmm ok
Make sure that CONFIG_PHYSICAL_START is 0x10.
Yeah it is.
x86-vmlinux-fix-physical-addrs.patch, perhaps..
I'll try.
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: 2.6.11-rc1-mm2

[Con Kolivas]

Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm2/
- There are a bunch of ioctl() and compat_ioctl() changes in here which seem
  to be of dubious maturity.  Could people involved in this area please
  review, test and let me know?
- A revamp of the kexec and crashdump patches.  Anyone who is interested in
  this work, please help to get this ball rolling a little faster?
- This kernel isn't particularly well-tested, sorry.  I've been a bit tied
  up with other stuff.
Wont boot.
Stops after BIOS check successful.
Tried reverting a couple of patches mentioning boot or reboot and had no 
luck. Any ideas?

P4HT3.06 on a P4PE motherboard.
dmesg of working boot:
Linux version 2.6.10-ck5 ([EMAIL PROTECTED]) (gcc version 3.4.3) #1 SMP Tue 
Jan 18 19:45:16 EST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 3ffec000 (usable)
 BIOS-e820: 3ffec000 - 3ffef000 (ACPI data)
 BIOS-e820: 3ffef000 - 3000 (reserved)
 BIOS-e820: 3000 - 4000 (ACPI NVS)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820:  - 0001 (reserved)
1023MB LOWMEM available.
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 22 low level)
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Kernel command line: BOOT_IMAGE=ck5 ro root=305 
[EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/
netconsole: local port 6665
netconsole: local IP 192.168.1.251
netconsole: interface eth0
netconsole: remote port 
netconsole: remote IP 192.168.1.1
netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
Initializing CPU#0
CPU 0 irqstacks, hard=b03b7000 soft=b03b5000
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 3105.371 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 131072 (order: 7, 524288 bytes)
Memory: 1035036k/1048496k available (1565k kernel code, 12932k reserved, 
1012k data, 168k init, 0k h
ighmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 3.06GHz stepping 07
per-CPU timeslice cutoff: 1462.74 usecs.
task migration cache decay timeout: 2 msecs.
Booting processor 1/1 eip 3000
CPU 1 irqstacks, hard=b03b8000 soft=b03b6000
Initializing CPU#1
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 3.06GHz stepping 07
Total of 2 processors activated (12320.76 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf1e50, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20041105
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, 
disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

[EMAIL PROTECTED] wrote:
On Thu, Jan 20, 2005 at 10:42:24AM -0500, Paul Davis wrote:
over on #ardour last week, we saw appalling performance from
reiserfs. a 120GB filesystem with 11GB of space failed to be able to
deliver enough read/write speed to keep up with a 16 track
session. When the filesystem was cleared to provide 36GB of space,
things improved. The actual recording takes place using writes of
256kB, and no more than a few hundred MB was being written during the
failed tests.

It's been a long while since I followed ReiserFS development closely,
*however*, this issue used to be a common problem ReiserFS - when
free space starts to drop below 10%, performace takes a big hit.  So
performance improved when space was cleared up.
I don't remember what causes this or what the status is in modern
ResierFS systems.

everything i read about reiser suggests it is unsuitable for audio
work: it is optimized around the common case of filesystems with many
small files. the filesystems where we record audio is typically filled
with a relatively small number of very, very large files.

Anecdotally, I've found this to not be the case.  I only use ReiserFS
and have a few reasonably sized projects in Ardour that work fine:
maybe 20 tracks, with 10-15 plugins (in the whole project), and I can
do overdubs with no problems.  It may be relevant that I only have a
four track card and so load is too small.
But at least in my practice, it hasn't been a huge hinderance.
This is my understanding of the situation, which is not gospel but 
interpretation of the information data I have had available.

Reiserfs3.6 is in maintenance mode. Its performance was very good in 2.4 
days, but since 2.6 the block layer has matured so much that the code 
paths that were fast in reiserfs are no longer so impressive compared to 
those shared by ext3.

In terms of recommendation, the latency of non-preemptible codepaths 
will be fastest in ext3 in 2.6 due to the nature of it constantly being 
examined, addressed and updated. That does not mean it has the fastest 
performance by any stretch of the imagination. XFS, I believe, has 
significantly faster large file performance, and reiser3.6 has 
significantly faster small file performance. But if throughput is not a 
problem, and latency is, then ext3 is a better choice. Reiser4 is a 
curious beast with obviously high throughput, but for the moment I do 
not think it is remotely suitable for low latency applications.

As for the %full issue; no filesystem works well as it approaches full 
capacity. Performance degrades dramatically beyond 75% on all of them, 
becoming woeful once beyond 85%. If you're looking for good performance, 
more free capacity is more effective than changing filesystems.

All of this should be taken into consideration if you're worried about 
low latency cpu scheduling, as it all will collapse if your filesystem 
code has high latency in the kernel. It also would make benchmarking low 
latency cpu scheduling potentially prone to disastrous mis-interpretation.

Cheers,
Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Alexander Nyberg wrote:
My simple yield DoS don't work anymore. But i found another way.
Running this as SCHED_ISO:

Yep, bad accounting in queue_iso() which relied on p->array == rq->active
This fixes it:
Index: vanilla/kernel/sched.c
===
--- vanilla.orig/kernel/sched.c	2005-01-20 18:05:59.0 +0100
+++ vanilla/kernel/sched.c	2005-01-20 18:41:26.0 +0100
@@ -2621,15 +2621,19 @@
 static task_t* queue_iso(runqueue_t *rq, prio_array_t *array)
 {
 	task_t *p = list_entry(rq->iso_queue.next, task_t, iso_list);
-	if (p->prio == MAX_RT_PRIO)
-		goto out;
+	prio_array_t *old_array = p->array;
+	
+	old_array->nr_active--;
 	list_del(&p->run_list);
-	if (list_empty(array->queue + p->prio))
-		__clear_bit(p->prio, array->bitmap);
+	if (list_empty(old_array->queue + p->prio))
+		__clear_bit(p->prio, old_array->bitmap);
+	
 	p->prio = MAX_RT_PRIO;
 	list_add_tail(&p->run_list, array->queue + p->prio);
 	__set_bit(p->prio, array->bitmap);
-out:
+	array->nr_active++;
+	p->array = array;
+	
 	return p;
 }
 

Excellent pickup, thanks!
Acked-by: Con Kolivas <[EMAIL PROTECTED]>


signature.asc
Description: OpenPGP digital signature

Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
Jack O'Quin wrote:
I was misreading the x-axis.  They're actually every 20 sec.  My
system isn't doing that.

Possibly reiserfs journal related. That has larger non-preemptible code 
sections.

You're really getting hammered with those periodic 6 msec delays,
though.  The basic audio cycle is only 1.45 msec.

As you've already pointed out, though, they occur even with SCHED_FIFO 
so I'm certain it's an artefact unrelated to cpu scheduling.
Ok to try and answer my own possibility I remounted reiserfs with the 
nolog option and tested with SCHED_ISO

*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 0
Delay Count (>spare time) . . : 1
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  6750   usecs
Cycle Maximum . . . . . . . . :   717   usecs
Average DSP Load. . . . . . . :30.7 %
Average CPU System Load . . . : 5.7 %
Average CPU User Load . . . . :23.2 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1683.8 /sec
Average Context-Switch Rate . : 20015.8 /sec
*
You'll see on
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/jack_test3-iso2-40c-nolog.png
That the 20s periodic thing delay has all but gone. Just one towards the 
end (no idea what that was).

Cheers,
Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
If I look at those png's locally (with gimp or gqview) they have a
dark grey checkerboard background.  If I look at them on the web (with
galeon), the background is white.  Go figure.  Maybe the file has no
background?  I dunno.
Yes there's no background so it depends on what you look at it with. 
Gene already pointed out the checkered background in gimp :)

I was misreading the x-axis.  They're actually every 20 sec.  My
system isn't doing that.
Possibly reiserfs journal related. That has larger non-preemptible code 
sections.

You're really getting hammered with those periodic 6 msec delays,
though.  The basic audio cycle is only 1.45 msec.
As you've already pointed out, though, they occur even with SCHED_FIFO 
so I'm certain it's an artefact unrelated to cpu scheduling.

Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

utz lehmann wrote:
I had experimented with throttling runaway RT tasks. I use a similar
accounting. I saw a difference between counting with or without the
calling from fork. If i remember correctly the timeout expired too fast
if the non-RT load was "while /bin/true; do :; done".
With "while true; do :; done" ("true" is bash buildin) it worked good.
But maybe it's not important in the real world.
It won't be relevant if we move to a sched_clock() based timesource 
anyway, which looks to be the next major development for this.

If i understand sched_clock correctly it only has higher resolution if
you can use tsc. In the non tsc case it's jiffies based. (On x86).
I think you can easily fool a timer tick/jiffies based accounting and do
a local DoS.
The same timer is used for accounting of SCHED_NORMAL tasks, so if you 
can work around that you can DoS the system with even the correct 
combination of SCHED_NORMAL tasks. When Ingo implemented sched_clock all 
the architectures slowly came on board. If I recall correctly the lowest 
resolution one still had microsecond accuracy which is more than enough 
given the time a context switch takes.

Making SCHED_ISO privileged if you don't have a high resolution
sched_clock is ugly.
I really like the idea of a unprivileged SCHED_ISO but it has to be safe
for a multi user system. And the kernel default should be safe for multi
user.
Agreed; this is exactly what this work is about.
Cheers,
Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Does it degrade significantly with a compile running in the background?
Check results below.
Full results and pretty pictures available here:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/
More pretty pictures with compile load on SCHED_ISO put up there now.
Outstanding.  

How do you get rid of that checkerboard grey background in the graphs?
Funny; that's the script you sent me so... beats me?
Looking at the graphs, your system has a substantial 4 to 6 msec delay
on approximately 40 second intervals, regardless of which scheduling
class or how many clients you run.  I'm guessing this is a recurring
long code path in the kernel and not a scheduling artifact at all.
Probably. No matter what I do the hard drive seems to keep trying to 
spin down. Might be related.

in the background:
while true ; do make clean && make ; done
SCHED_ISO with 40 clients:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 3
Delay Count (>spare time) . . :20
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  5841   usecs
Cycle Maximum . . . . . . . . :   891   usecs
Average DSP Load. . . . . . . :34.1 %
Average CPU System Load . . . :10.7 %
Average CPU User Load . . . . :87.8 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.7 %
Average CPU IRQ Load  . . . . : 0.8 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1711.4 /sec
Average Context-Switch Rate . : 20751.6 /sec
*
Cheers,
Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

Con Kolivas wrote:
Here are my results with SCHED_ISO v2 on a pentium-M 1.7Ghz (all
powersaving features off):
Increasing iso_cpu did not change the results.
At least in my testing on my hardware, v2 is working as advertised. I
need results from more hardware configurations to know if priority
support is worth adding or not.

Excellent.  Judging by the DSP Load, your machine seems to run almost
twice as fast as my 1.5GHz Athlon (surprising).  You might want to try
Not really surprising; the 2Mb cache makes this a damn fine cpu, if not 
necessarily across the board :)

pushing it a bit harder by running more clients (2nd parameter,
default is 20).
Ask and ye shall receive.
Are you getting fairly consistent results running SCHED_ISO
repeatedly?  That worked better for me after I fixed that bug in JACK
0.99.47, but I think there is still more variance than with
SCHED_FIFO.
Much more consistent, and I believe some bugs in the earlier 
implementation were probably biting.

40 clients:
SCHED_FIFO:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 7
Delay Count (>spare time) . . :20
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  6739   usecs
Cycle Maximum . . . . . . . . :   746   usecs
Average DSP Load. . . . . . . :30.4 %
Average CPU System Load . . . : 5.7 %
Average CPU User Load . . . . :23.3 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1692.0 /sec
Average Context-Switch Rate . : 20907.7 /sec
*
SCHED_ISO:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :11
Delay Count (>spare time) . . :19
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  8723   usecs
Cycle Maximum . . . . . . . . :   714   usecs
Average DSP Load. . . . . . . :31.1 %
Average CPU System Load . . . : 5.7 %
Average CPU User Load . . . . :23.2 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1685.4 /sec
Average Context-Switch Rate . : 20496.9 /sec
*
Full results and pretty pictures available here:
http://ck.kolivas.org/patches/SCHED_ISO/iso2-benchmarks/
Cheers,
Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
This is version 2 of the SCHED_ISO patch with the yield bug fixed and 
code cleanups.
...answering on this thread to consolidate the two branches of the email 
thread.

Here are my results with SCHED_ISO v2 on a pentium-M 1.7Ghz (all 
powersaving features off):

SCHED_NORMAL:
awk: ./jack_test3_summary.awk:67: (FILENAME=- FNR=862) fatal: division 
by zero attempted
Well we wont bother looking at those results then. there were 38 XRUNS 
that did make it on the parsed output.

SCHED_FIFO:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 4
Delay Count (>spare time) . . :18
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  6595   usecs
Cycle Maximum . . . . . . . . :   368   usecs
Average DSP Load. . . . . . . :17.9 %
Average CPU System Load . . . : 3.4 %
Average CPU User Load . . . . :13.7 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 1.4 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1697.0 /sec
Average Context-Switch Rate . : 13334.1 /sec
*
SCHED_ISO (iso_cpu 70):
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 5
Delay Count (>spare time) . . :18
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . :  6489   usecs
Cycle Maximum . . . . . . . . :   405   usecs
Average DSP Load. . . . . . . :18.0 %
Average CPU System Load . . . : 3.3 %
Average CPU User Load . . . . :13.7 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.6 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1700.2 /sec
Average Context-Switch Rate . : 12457.2 /sec
*
Increasing iso_cpu did not change the results.
At least in my testing on my hardware, v2 is working as advertised. I 
need results from more hardware configurations to know if priority 
support is worth adding or not.

Cheers,
Con
-
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: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

utz lehmann wrote:
@@ -2406,6 +2489,10 @@ void scheduler_tick(void)
 	task_t *p = current;
 
 	rq->timestamp_last_tick = sched_clock();
+	if (iso_task(p) && !rq->iso_refractory)
+		inc_iso_ticks(rq, p);
+	else 
+		dec_iso_ticks(rq, p);

scheduler_tick() is not only called by the timer interrupt but also form
the fork code. Is this intended? I think the accounting for
The calling from fork code only occurs if there is one millisecond of 
time_slice left so it will only very rarely be hit. I dont think this 
accounting problem is worth worrying about.

iso_refractory is wrong. Isn't calling it from
timer.c::update_process_times() better?
And shouldn't real RT task also counted? If RT tasks use 40% cpu you can
lockup the system as unprivileged user with SCHED_ISO because it doesn't
reach the 70% cpu limit.
Ah yes. Good point. Will add that to the equation.
Futher on i see a fundamental problem with this accounting for
iso_refractory. What if i manage as unprivileged user to run a SCHED_ISO
task which consumes all cpu and only sleeps very short during the timer
interrupt? I think this will nearly lockup or very slow down the system.
The iso_cpu limit can't guaranteed.
Right you are. The cpu accounting uses primitive on-interrupt run time 
which as we know is not infallible. To extend this I'll have to keep a 
timer based on the sched_clock which is already implemented. That's 
something for me to work on.

sysrq-n causes a reboot.
And that will need looking into.
Thanks very much for your comments!
Cheers,
Con
-
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: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Try again with JACK 0.99.48.  It's in CVS now, but you probably need
this tarball to get around the dreaded SourceForge anon CVS lag...
   http://www.joq.us/jack/tarballs/jack-audio-connection-kit-0.99.48.tar.gz
Thanks it finally ran to completion. By the way the patch you sent with 
the test suite did not apply so I had to do it manually (booraroom..)

The results I get with these versions are a lot more stable.  But,
there are still some puzzles about the scheduling.  Do you distinguish
different SCHED_ISO priorities?  
It was not clear whether that would be required or not. This is why 
testing is so critical because if you are having latency issues it 
wouldn't be a problem of getting cpu time since your cpu usage is well 
below the 70% limit.

JACK runs with three different SCHED_FIFO priorities:
  (1) The main jackd audio thread uses the -P parameter.  The JACK
  default is 10, but Rui's script sets it with -P60.  I don't think
  the absolute value matters, but the value relative to the other JACK
  realtime threads probably does.
  (2) The clients' process threads run at a priority one less (59).
  (3) The watchdog timer thread runs at a priority 10 greater (70).
  (4) LinuxThreads creates a manager thread in each process running
  one level higher than the highest user realtime thread priority.
Since I (finally) have it running at this end at last I'll do some 
benchmarking of my own to see how (lack of) priorities affects 
SCHED_ISO. If it is inadequate, it wont be too difficult to add them to 
the design. The problem with priorities is that once you go over the cpu 
limit everyone suffers equally; but that's a failsafe that you shouldn't 
actually hit in normal usage so it probably doesn't matter... Hmm come 
to think of it, it probably _is_ a good idea to implement priority 
support afterall.

Cheers,
Con
-
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/

[PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

[Con Kolivas]

This is version 2 of the SCHED_ISO patch with the yield bug fixed and 
code cleanups.

This patch for 2.6.11-rc1 provides a method of providing real time
scheduling to unprivileged users which increasingly is desired for
multimedia workloads.
It does this by adding a new scheduling class called SCHED_ISO or
Isochronous scheduling which means "same time" scheduling. This class
does not require superuser privileges and is starvation free. The
scheduling class no. 4 was chosen since there are quite a few userspace
applications already supporting 3 and 4 for SCHED_BATCH and SCHED_ISO
respectively on non-mainline kernels. As a way of immediately providing
support for current userspace apps, any unprivileged user starting an
application requesting SCHED_RR or SCHED_FIFO will be demoted to
SCHED_ISO. This may or may not be worth removing later.
The SCHED_ISO class runs as SCHED_RR effectively at a priority just
above all SCHED_NORMAL tasks and below all true real time tasks. Once a
cpu usage limit is exceeded by tasks of this class (per cpu), SCHED_ISO
tasks will then run as SCHED_NORMAL until the cpu usage drops to 90% of
the cpu limit.
By default the cpu limit is set to 70% which literature suggests should
provide good real time behaviour for most applications without gross
unfairness. This cpu limit is calculated as a decaying average over 5
seconds. These limits are configurable with the tunables
/proc/sys/kernel/iso_cpu
/proc/sys/kernel/iso_period
iso_cpu can be set to 100 which would allow all unprivileged users
access to unrestricted SCHED_RR behaviour. OSX provides a similar class
to SCHED_ISO and uses 90% as its cpu limit.
The sysrq-n combination which converts all user real-time tasks to
SCHED_NORMAL also will affect SCHED_ISO tasks.
Currently the round robin interval is set to 10ms which is a cache
friendly timeslice. It may be worth making this configurable or smaller,
and it would also be possible to implement SCHED_ISO of a FIFO nature as
well.
For testing, the userspace tool schedtool available here:
http://freequaos.host.sk/schedtool/
can be used as a wrapper to start SCHED_ISO tasks
schedtool -I -e xmms
for example
Patch also available here:
http://ck.kolivas.org/patches/SCHED_ISO/
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc1-iso/include/linux/init_task.h
===
--- linux-2.6.11-rc1-iso.orig/include/linux/init_task.h	2005-01-20 09:19:29.0 +1100
+++ linux-2.6.11-rc1-iso/include/linux/init_task.h	2005-01-20 09:19:31.0 +1100
@@ -80,6 +80,7 @@ extern struct group_info init_groups;
 	.mm		= NULL,		\
 	.active_mm	= &init_mm,	\
 	.run_list	= LIST_HEAD_INIT(tsk.run_list),			\
+	.iso_list	= LIST_HEAD_INIT(tsk.iso_list),			\
 	.time_slice	= HZ,		\
 	.tasks		= LIST_HEAD_INIT(tsk.tasks),			\
 	.ptrace_children= LIST_HEAD_INIT(tsk.ptrace_children),		\
Index: linux-2.6.11-rc1-iso/include/linux/sched.h
===
--- linux-2.6.11-rc1-iso.orig/include/linux/sched.h	2005-01-20 09:19:29.0 +1100
+++ linux-2.6.11-rc1-iso/include/linux/sched.h	2005-01-20 09:19:31.0 +1100
@@ -130,6 +130,18 @@ extern unsigned long nr_iowait(void);
 #define SCHED_NORMAL		0
 #define SCHED_FIFO		1
 #define SCHED_RR		2
+/* policy 3 reserved for SCHED_BATCH */
+#define SCHED_ISO		4
+
+extern int iso_cpu, iso_period;
+
+#define SCHED_RANGE(policy)	((policy) == SCHED_NORMAL || \
+(policy) == SCHED_FIFO || \
+(policy) == SCHED_RR || \
+(policy) == SCHED_ISO)
+
+#define SCHED_RT(policy)	((policy) == SCHED_FIFO || \
+(policy) == SCHED_RR)
 
 struct sched_param {
 	int sched_priority;
@@ -359,6 +371,7 @@ struct signal_struct {
 #define MAX_PRIO		(MAX_RT_PRIO + 40)
 
 #define rt_task(p)		(unlikely((p)->prio < MAX_RT_PRIO))
+#define iso_task(p)		(unlikely((p)->policy == SCHED_ISO))
 
 /*
  * Some day this will be a full-fledged user tracking system..
@@ -536,6 +549,7 @@ struct task_struct {
 
 	int prio, static_prio;
 	struct list_head run_list;
+	struct list_head iso_list;
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
Index: linux-2.6.11-rc1-iso/include/linux/sysctl.h
===
--- linux-2.6.11-rc1-iso.orig/include/linux/sysctl.h	2005-01-20 09:19:29.0 +1100
+++ linux-2.6.11-rc1-iso/include/linux/sysctl.h	2005-01-20 09:19:31.0 +1100
@@ -135,6 +135,8 @@ enum
 	KERN_HZ_TIMER=65,	/* int: hz timer on or off */
 	KERN_UNKNOWN_NMI_PANIC=66, /* int: unknown nmi panic flag */
 	KERN_BOOTLOADER_TYPE=67, /* int: boot loader type */
+	KERN_ISO_CPU=68,	/* int: cpu% allowed by SCHED_ISO class */
+	KERN_ISO_PERIOD=69,	/* int: seconds over which SCHED_ISO cpu is decayed */
 };
 
 
Index: linux-2.6.11-rc1-iso/kernel/sched.c
===
--- linux-2.6.11-rc1-iso.orig/kernel/sched.c	2005-01-20 09:19

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Just as a headsup there is a new cleaned up patch here:
http://ck.kolivas.org/patches/SCHED_ISO/2.6.11-rc1-iso-0501192240.diff
The yield bug is still eluding my capture but appears to be related to 
the array switch of yielding and rescheduling as ISO after the fact. 
Still working on it.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

This patch for 2.6.11-rc1 provides a method of providing real time
scheduling to unprivileged users which increasingly is desired for
multimedia workloads.

I ran some jack_test3.2 runs with this, using all the default
settings.  The results of three runs differ quite significantly for no
obvious reason.  I can't figure out why the DSP load should vary so
much.  
I installed a fresh jack installation and got the test suite. I tried 
running the test suite and found it only ran to completion if I changed 
the run time right down to 30 seconds from 300. Otherwise it bombed out 
almost instantly at the default of 300. I don't know if that helps you 
debug the problem or not but it might be worth mentioning.

As for my own results I gave it a run on the weak SCHED_ISO 
implementation in 2.6.10-ck5 (P4HT 3.06):

SCHED_NORMAL:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :74
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 0   usecs
Cycle Maximum . . . . . . . . :  1046   usecs
Average DSP Load. . . . . . . :18.0 %
Average CPU System Load . . . : 2.5 %
Average CPU User Load . . . . : 7.8 %
Average CPU Nice Load . . . . : 0.1 %
Average CPU I/O Wait Load . . : 0.1 %
Average CPU IRQ Load  . . . . : 0.1 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate  . . . :  1776.0 /sec
Average Context-Switch Rate . : 10290.4 /sec
*
SCHED_NORMAL nice -n -20:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . :   266
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 0   usecs
Cycle Maximum . . . . . . . . :  2239   usecs
Average DSP Load. . . . . . . :28.6 %
Average CPU System Load . . . : 2.9 %
Average CPU User Load . . . . :10.2 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 1.0 %
Average CPU IRQ Load  . . . . : 0.2 %
Average CPU Soft-IRQ Load . . : 0.1 %
Average Interrupt Rate  . . . :  2049.7 /sec
Average Context-Switch Rate . : 10145.1 /sec
*
SCHED_ISO:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 1
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 0   usecs
Cycle Maximum . . . . . . . . :   687   usecs
Average DSP Load. . . . . . . :19.9 %
Average CPU System Load . . . : 2.6 %
Average CPU User Load . . . . :10.3 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 0.2 %
Average CPU Soft-IRQ Load . . : 0.3 %
Average Interrupt Rate  . . . :  2166.2 /sec
Average Context-Switch Rate . : 10117.3 /sec
*
SCHED_FIFO:
*
Timeout Count . . . . . . . . :(0)
XRUN Count  . . . . . . . . . : 2
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 0   usecs
Cycle Maximum . . . . . . . . :   544   usecs
Average DSP Load. . . . . . . :19.5 %
Average CPU System Load . . . : 3.1 %
Average CPU User Load . . . . :12.6 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 0.0 %
Average CPU IRQ Load  . . . . : 1.0 %
Average CPU Soft-IRQ Load . . : 1.1 %
Average Interrupt Rate  . . . :  5018.4 /sec
Average Context-Switch Rate . : 10902.5 /sec
*
It occasionally would segfault on client exit as well (as you've already 
mentioned). I think we're still in the dark here to be honest.

Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:

This patch for 2.6.11-rc1 provides a method of providing real time
scheduling to unprivileged users which increasingly is desired for
multimedia workloads.

I ran some jack_test3.2 runs with this, using all the default
settings.  The results of three runs differ quite significantly for no
obvious reason.  I can't figure out why the DSP load should vary so
much.  

These may be bogus results.  It looks like a libjack bug sometimes
causes clients to crash when deactivating.  I will investigate more
tomorrow, and come up with a fix.
For comparison, I also made a couple of runs using the realtime-lsm to
grant SCHED_FIFO privileges.  There was some variablility, but nowhere
near as much (and no crashes).  I used schedtool to verify that the
jackd threads actually have the expected scheduler type.
Thanks for those. If you don't know what to make of the dsp variation 
and the crashing then I'm not sure what I should make of it either. It's 
highly likely that my code still needs fixing to ensure it behaves as 
expected. Already one bug has been picked up in testing with respect to 
yield() so there may be others. By design, if you set iso_cpu to 100 it 
should be as good as SCHED_RR. If not, then the implementation is still 
buggy.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

utz wrote:
Hi Con
I just played with your SCHED_ISO patch and found a simple way to crash
my machine.
I'm running this as unprivileged user with SCHED_ISO:
main ()
{
while(1) {
sched_yield();
}
}
The system hangs about 3s and then reboots itself.
2.6.11-rc1 + 2.6.11-rc1-iso-0501182249 on an UP Athlon XP.
With real SCHED_FIFO it just lockup the system.
Thanks I'll look into it.
Cheers,
Con
-
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] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Lee Revell wrote:
On Tue, 2005-01-18 at 10:17 -0600, Jack O'Quin wrote:
Cal <[EMAIL PROTECTED]> writes:

There's a collection of test summaries from jack_test3.2 runs at

Tests were run with iso_cpu at 70, 90, 99, 100, each test was run
twice. The discrepancies between consecutive runs (with same
parameters) is puzzling.  Also recorded were tests with SCHED_FIFO and
SCHED_RR.
It's probably suffering from some of the same problems of thread
granularity we saw running nice --20.  It looks like you used
schedtool to start jackd.  IIUC, that will cause all jackd processes
to run in the specified scheduling class.  JACK is carefully written
not to do that.  Did you also use schedtool to start all the clients?
I think your puzzling discrepancies are probably due to interference
from non-realtime JACK threads running at elevated priority.

Isn't this going to be a showstopper?  If I understand the scheduler
correctly, a nice -20 task is not guaranteed to preempt a nice -19 task,
if the scheduler decides that one is more CPU bound than the other and
lowers its dynamic priority.  The design of JACK, however, requires the
higher priority threads to *always* preempt the lower ones.
The point was the application was started in a manner which would not 
make best use of this policy. The way it was started put everything 
under the same policy, and had equal performance with doing the same 
thing as SCHED_FIFO. So if it's a showstopper for SCHED_ISO then it is a 
showstopper for SCHED_FIFO. Which is, of course, not the case. The test 
needs to be performed again with the rt threads running SCHED_ISO, which 
 Jack has pointed out is trivial. Nice -n -20 on the other hand will 
suffer from this problem even if only the real time thread was run at -20.

Cheers,
Con
-
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] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Cal wrote:
Con Kolivas wrote:
Comments and testing welcome.

There's a collection of test summaries from jack_test3.2 runs at
<http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt>
Tests were run with iso_cpu at 70, 90, 99, 100, each test was run twice. 
The discrepancies between consecutive runs (with same parameters) is 
puzzling.  Also recorded were tests with SCHED_FIFO and SCHED_RR.

Before drawing any hardball conclusions, verification of the results 
would be nice. At first glance, it does seem that we still have that 
fateful gap between "harm minimisation" (policy) and "zero tolerance" 
(audio reality requirement).
Thanks.
SCHED_ISO
/proc/sys/kernel/iso_cpu . . .: 70
/proc/sys/kernel/iso_period . : 5
XRUN Count  . . . . . . . . . :   110
vs
SCHED_FIFO
XRUN Count  . . . . . . . . . :   114
XRUN Count  . . . . . . . . . :   187
vs
SCHED_RR
XRUN Count  . . . . . . . . . : 0
XRUN Count  . . . . . . . . . : 0
Something funny going on here... You had more xruns with SCHED_FIFO than 
the default SCHED_ISO settings, and had none with SCHED_RR. Even in the 
absence of the SCHED_ISO results, the other results dont make a lot of 
sense.

Con
P.S. If you're running on SMP it may be worth booting on UP or using cpu 
affinity (schedtool -a 0x1 will bind you to 1st cpu only) and see what 
effect that is having. There are some interesting things that can 
adversely affect latency on SMP.


signature.asc
Description: OpenPGP digital signature

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
This patch for 2.6.11-rc1 provides a method of providing real time
scheduling to unprivileged users which increasingly is desired for
multimedia workloads.
I should have mentioned. Many thanks to Alex Nyberg for generous 
debugging help.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

2.6.10-ck5

[Con Kolivas]

These are patches designed to improve system responsiveness. It is 
configurable to any workload but the default ck* patch is aimed at the 
desktop and ck*-server is available with more emphasis on serverspace.

http://ck.kolivas.org/patches/2.6/2.6.10/2.6.10-ck5/
web:
http://kernel.kolivas.org
all patches:
http://ck.kolivas.org/patches/
This is a maintenance release concentrating on getting a stable and 
hopefully last 2.6.10 release.

A lot of instability manifested by processes stuck in D was caused by 
the early adoption of cfq-timeslices with priority support. This project 
is very exciting, but is not yet suitable for a stable patchset.

Note that gamers are reporting very good audio performance with 
staircase10.3 and higher even on cedega/wineX games.

Removed:
-inc_total_scanned.diff
-2.6.10-capabilities_fix.diff
-linux-2.6.7-CAN-2004-1056.patch
-linux-2.6.9-smbfs.patch
-2.6.10-mm1-brk-locked.patch
-random-poolsize-int-overflow.diff
-rlimit-memlock-dos.diff
-scsi-int-overflow-information-leak.diff
-moxa-int-overflow.diff
All rolled up with -as patchset
-cfq-ts-20.diff
-isobatch_ionice.diff
-rt_ionice.diff
-cfq_writeprio_on.diff
The cfq timeslices patch and related changes
Added:
+patch-2.6.10-as2
The nifty -as patchset containing security and obvious fixes.
+s10.3_s10.4.diff
+s10.4_s10.5.diff
Updated staircase code.
Full patchlist:
patch-2.6.10-as2
2.6.10_to_staircase9.2.diff
schedrange.diff
schedbatch2.6.diff
schediso2.8.diff
mwII.diff
1g_lowmem1_i386.diff
defaultcfq.diff
2.6.10-mingoll.diff
cddvd-cmdfilter-drop.patch
vm-pageout-throttling.patch
nvidia_6111-6629_compat2.diff
fix-ll-resume.diff
s9.2_s9.3.diff
i2.8_i2.9.diff
s9.3_s9.4.diff
i2.9_i2.10.diff
b2.6_b2.7.diff
s9.4_s10.diff
s10_test1.diff
s10_s10.1.diff
s10.1_s10.2.diff
s10.2_s10.3.diff
1504_vmscan-writeback-pages.patch
s10.3_s10.4.diff
s10.4_s10.5.diff
2610ck5-version.diff
and available in patches/ separately:
supermount-ng208-10ck5.diff
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

[PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

This patch for 2.6.11-rc1 provides a method of providing real time
scheduling to unprivileged users which increasingly is desired for
multimedia workloads.
It does this by adding a new scheduling class called SCHED_ISO or
Isochronous scheduling which means "same time" scheduling. This class
does not require superuser privileges and is starvation free. The
scheduling class no. 4 was chosen since there are quite a few userspace
applications already supporting 3 and 4 for SCHED_BATCH and SCHED_ISO
respectively on non-mainline kernels. As a way of immediately providing
support for current userspace apps, any unprivileged user starting an
application requesting SCHED_RR or SCHED_FIFO will be demoted to
SCHED_ISO. This may or may not be worth removing later.
The SCHED_ISO class runs as SCHED_RR effectively at a priority just
above all SCHED_NORMAL tasks and below all true real time tasks. Once a
cpu usage limit is exceeded by tasks of this class (per cpu), SCHED_ISO
tasks will then run as SCHED_NORMAL until the cpu usage drops to 90% of
the cpu limit.
By default the cpu limit is set to 70% which literature suggests should
provide good real time behaviour for most applications without gross
unfairness. This cpu limit is calculated as a decaying average over 5
seconds. These limits are configurable with the tunables
/proc/sys/kernel/iso_cpu
/proc/sys/kernel/iso_period
iso_cpu can be set to 100 which would allow all unprivileged users
access to unrestricted SCHED_RR behaviour. OSX provides a similar class
to SCHED_ISO and uses 90% as its cpu limit.
The sysrq-n combination which converts all user real-time tasks to
SCHED_NORMAL also will affect SCHED_ISO tasks.
Currently the round robin interval is set to 10ms which is a cache
friendly timeslice. It may be worth making this configurable or smaller,
and it would also be possible to implement SCHED_ISO of a FIFO nature as
well.
For testing, the userspace tool schedtool available here:
http://freequaos.host.sk/schedtool/
can be used as a wrapper to start SCHED_ISO tasks
schedtool -I -e xmms
for example
Patch also available here:
http://ck.kolivas.org/patches/SCHED_ISO/
Comments and testing welcome.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc1/include/linux/init_task.h
===
--- linux-2.6.11-rc1.orig/include/linux/init_task.h	2005-01-16 22:43:47.0 +1100
+++ linux-2.6.11-rc1/include/linux/init_task.h	2005-01-16 22:45:23.0 +1100
@@ -80,6 +80,7 @@
 	.mm		= NULL,		\
 	.active_mm	= &init_mm,	\
 	.run_list	= LIST_HEAD_INIT(tsk.run_list),			\
+	.iso_list	= LIST_HEAD_INIT(tsk.iso_list),			\
 	.time_slice	= HZ,		\
 	.tasks		= LIST_HEAD_INIT(tsk.tasks),			\
 	.ptrace_children= LIST_HEAD_INIT(tsk.ptrace_children),		\
Index: linux-2.6.11-rc1/include/linux/sched.h
===
--- linux-2.6.11-rc1.orig/include/linux/sched.h	2005-01-16 22:43:47.0 +1100
+++ linux-2.6.11-rc1/include/linux/sched.h	2005-01-18 22:48:05.0 +1100
@@ -130,6 +130,18 @@
 #define SCHED_NORMAL		0
 #define SCHED_FIFO		1
 #define SCHED_RR		2
+/* policy 3 reserved for SCHED_BATCH */
+#define SCHED_ISO		4
+
+extern int iso_cpu, iso_period;
+
+#define SCHED_RANGE(policy)	((policy) == SCHED_NORMAL || \
+(policy) == SCHED_FIFO || \
+(policy) == SCHED_RR || \
+(policy) == SCHED_ISO)
+
+#define SCHED_RT(policy)	((policy) == SCHED_FIFO || \
+(policy) == SCHED_RR)
 
 struct sched_param {
 	int sched_priority;
@@ -359,6 +371,7 @@
 #define MAX_PRIO		(MAX_RT_PRIO + 40)
 
 #define rt_task(p)		(unlikely((p)->prio < MAX_RT_PRIO))
+#define iso_task(p)		(unlikely((p)->policy == SCHED_ISO))
 
 /*
  * Some day this will be a full-fledged user tracking system..
@@ -536,6 +549,7 @@
 
 	int prio, static_prio;
 	struct list_head run_list;
+	struct list_head iso_list;
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
Index: linux-2.6.11-rc1/include/linux/sysctl.h
===
--- linux-2.6.11-rc1.orig/include/linux/sysctl.h	2005-01-16 22:43:47.0 +1100
+++ linux-2.6.11-rc1/include/linux/sysctl.h	2005-01-16 22:45:23.0 +1100
@@ -135,6 +135,8 @@
 	KERN_HZ_TIMER=65,	/* int: hz timer on or off */
 	KERN_UNKNOWN_NMI_PANIC=66, /* int: unknown nmi panic flag */
 	KERN_BOOTLOADER_TYPE=67, /* int: boot loader type */
+	KERN_ISO_CPU=68,	/* int: cpu% allowed by SCHED_ISO class */
+	KERN_ISO_PERIOD=69,	/* int: seconds over which SCHED_ISO cpu is decayed */
 };
 
 
Index: linux-2.6.11-rc1/kernel/sched.c
===
--- linux-2.6.11-rc1.orig/kernel/sched.c	2005-01-16 22:43:47.0 +1100
+++ linux-2.6.11-rc1/kernel/sched.c	2005-01-18 22:48:47.0 +1100
@@ -149,9 +149,6 @@
 	(JIFFIES_TO_NS(MAX_SLEEP_AVG * \
 		(MAX_BONUS / 2 + DELTA((p)) + 1) / MAX_BONUS - 1))
 
-#define TASK_PREEMPTS_CUR