Scheduler issue 1, RT tasks ...
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 35 lines · Dieter Nützel
Quoted 23 lines · Martin Knoblauch
Quoted 6 lines
Re: [RFC] Scheduler issue 1, RT tasks ...
Quoted 2 lines
Right, that was my question. George says, in your words, "for better
Quoted 8 lines
Quoted 1 line
standards compliancy ..." and I want to know why you guys think
that.
The thought was that if someone need RT tasks he probably need a very low latency and so the idea that by applying global preemption decisions would lead to a better compliancy. But i'll be happy to ear that this is false anyway ...
without wanting to start a RT flame-fest, what do people really want
when they talk about RT in this [Linux] context:- very low latency
- deterministic latency ("never to exceed")
- both
- something completely differentQuoted 9 lines
All of the above from time to time and user to user. That is, some folks want one or more of the above, some folks want more, some less. What is really up? Well they have a job to do that requires certain things. Different jobs require different capabilities. It is hard to say that any given system will do a reasonably complex job with out testing. For example we may have the required latency but find the system fails because, to get the latency, we preempted another task that was (and so still is) in the middle of updating something we need to complete the job.
Quoted 5 lines
So George what direction should I try for some tests? 2.4.17 plus your and Robert's preempt plus lock-break? Add your high-res-timers, rtscheduler or both? Do they apply against 2.4.17/2.4.18-pre1?
A combination of the above plus Davide's BMQS?
I would guess you want preempt plus lock-break at least. rtsched may give a small improvement if you run any real time (i.e. not SCHED_OTHER) tasks (and the improvement should be in both real time and non-real time preemption) but, in general, the schedule is not any where near the problem the long held locks are so I really don't expect to see much improvement here. If you have a lot of task on the system (not active, just there) you may see the "recalculate" with the standard scheduler which is much improved with rtsched (it does not include tasks not in the run list in the recalculate).
As for high-res-timers, I just put out a 2.4.13 version which should work on 2.4.17 (there are rejects in the patch, but all in non-i386 code). I have one report, however, of asm errors which seem to depend on the compiler (or asm) version. I will look into this and put up a 2.4.17 version early next week. Testing wise, I don't think this will be visible because you most likely are not using POSIX timers. There is a change in the timer list structure, but that should be in the noise also. In short, the high-res-timers project provides new capability, not improved performance with existing capability.
Quoted 4 lines
I ask because my MP3/Ogg-Vorbis hiccup during dbench isn't solved anyway. Running 2.4.17 + preempt + lock-break + 10_vm-21 (AA).
Some wisdom?
Try the preempt-stats patch and collect data during the hiccup. It should point the finger at the problem. Let us know what you find. Robert has been very good at fixing things like this with his lock-break stuff, but we/he need to know who the bad guy is.
Quoted 12 lines
Thank you for all your work and
Happy New Year-Dieter
--
Dieter Nützel
Graduate Student, Computer ScienceUniversity of Hamburg
Department of Computer Science
@home: [email protected]
Signature · 3 lines
George [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/
Quoted 11 lines · you
Quoted 4 lines · Dieter Nützel
I ask because my MP3/Ogg-Vorbis hiccup during dbench isn't solved anyway. Running 2.4.17 + preempt + lock-break + 10_vm-21 (AA).
Some wisdom?Please test this elevator patch. I'll be putting it out more formally in a day or two. Much more testing is needed yet, but for me, the time to read a 16 megabyte file whilst running dbench 160 falls from three minutes thirty seconds to seven seconds. (This is a VM thing, not an elevator thing).
Andrew or anybody else,
can you please send me a copy directly?
The version I've extracted from the list is some what broken.
I am not on LKML 'cause it is to much traffic for such a poor little boy like me...;-)
Thanks,
Dieter
Quoted 14 lines · Dieter Nützel
Quoted 11 lines · you
Quoted 4 lines · Dieter Nützel
I ask because my MP3/Ogg-Vorbis hiccup during dbench isn't solved anyway. Running 2.4.17 + preempt + lock-break + 10_vm-21 (AA).
Some wisdom?Please test this elevator patch. I'll be putting it out more formally in a day or two. Much more testing is needed yet, but for me, the time to read a 16 megabyte file whilst running dbench 160 falls from three minutes thirty seconds to seven seconds. (This is a VM thing, not an elevator thing).
Quoted 7 lines
Andrew or anybody else,
can you please send me a copy directly?
The version I've extracted from the list is some what broken.
I am not on LKML 'cause it is to much traffic for such a poor little boy like me...;-)
Andrew,
I think the problem is that the mailer(s) insert new lines. Is this right Dieter? It is certainly a problem for me.
Best to mail as an attachment.
Signature · 3 lines
George [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/
Quoted 20 lines · george anzinger
Quoted 12 lines · Dieter Nützel
Quoted 10 lines · you
Quoted 3 lines · Dieter Nützel
I ask because my MP3/Ogg-Vorbis hiccup during dbench isn't solved anyway. Running 2.4.17 + preempt + lock-break + 10_vm-21 (AA). Some wisdom?
Please test this elevator patch. I'll be putting it out more formally in a day or two. Much more testing is needed yet, but for me, the time to read a 16 megabyte file whilst running dbench 160 falls from three minutes thirty seconds to seven seconds. (This is a VM thing, not an elevator thing).
Quoted 6 lines
Andrew or anybody else,
can you please send me a copy directly?
The version I've extracted from the list is some what broken. I am not on LKML 'cause it is to much traffic for such a poor little boy like me...;-)
Quoted 4 lines
Andrew,
I think the problem is that the mailer(s) insert new lines. Is this right Dieter? It is certainly a problem for me.
Yes.
Quoted 1 line
Best to mail as an attachment.
Yes.
But I applied it by hand and got the best results I ever had! GREAT work, Andrew!
This should be go in, soon.
2.4.17
preempt-kernel-rml-2.4.17-1.patch
lock-break-rml-2.4.17-2.patch
00_nanosleep-5
10_vm-21 (Andrea)
bootmem-2.4.17-pre6
elevator-fix (Andrew)
O-inode-attrs.patch (ReiserFS)
linux-2.4.17rc2-KLMN+exp_trunc+3fixes.patch (ReiserFS)
Happy New Year and best wishes!
-Dieter
BTW Below are my first results. More to come (analysis of latency).
2.4.17-preempt + 10_vm-21 + elevator
dbench/dbench> time ./dbench 32
32 clients started
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................+.................................................................+...................+.......+....................+.........................................................................................................+.........+....................+................+..................+.....+...................................................................................................................................................................................................................................................................+..............++...........+.+.+..++++.+++.+.+++.++++********************************
Throughput 49.7707 MB/sec (NB=62.2133 MB/sec 497.707 MBit/sec)
13.800u 51.810s 1:25.89 76.3% 0+0k 0+0io 939pf+0w
2.4.17-preempt + 10_vm-21 + elevator + MP3 playback dbench/dbench> time ./dbench 32
32 clients started
..............................................................................................................................................................................................................................................................................................................................................+.................................++....+.+.+.......+.............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................+......................++.....+..+++.++..++.++++.+....++++.+++++********************************
Throughput 48.6323 MB/sec (NB=60.7904 MB/sec 486.323 MBit/sec)
14.690u 52.920s 1:27.87 76.9% 0+0k 0+0io 939pf+0w