Fixes spurious system load spikes in /proc/loadavgrt
PATCH 1/1 Fixes spurious system load spikes in /proc/loadavgrt
Hello,
The values in /proc/loadavgrt are sometimes the real load and sometimes garbage. As you can see in th tests below, it occurs from in 2.6.21.5-rt20 to 2.6.23-rc2-rt2. The code for calc_load(), in kernel/timer.c has not changed much in -rt patches.
[lclaudio@lab sandbox]$ ls /proc/loadavg*
/proc/loadavg /proc/loadavgrt
[lclaudio@lab sandbox]$ uname -a
Linux lab.casa 2.6.21-34.el5rt #1 SMP PREEMPT RT Thu Jul 12 15:26:48 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
[lclaudio@lab sandbox]$ cat /proc/loadavg*
4.57 4.90 4.16 3/146 23499
0.44 0.98 1.78 0/146 23499
...
[lclaudio@lab sandbox]$ cat /proc/loadavg*
4.65 4.80 4.75 5/144 20720
23896.04 -898421.23 383170.94 2/144 20720
[root@neverland ~]# uname -a
Linux neverland.casa 2.6.21.5-rt20 #2 SMP PREEMPT RT Fri Jul 1318:31:38 BRT 2007 i686 athlon i386 GNU/Linux
[root@neverland ~]# cat /proc/loadavg*
0.16 0.16 0.15 1/184 11240
344.65 0.38 311.71 0/184 11240
[williams@torg ~]$ uname -a
Linux torg 2.6.23-rc2-rt2 #14 SMP PREEMPT RT Tue Aug 7 20:07:31 CDT 2007 x86_64 x86_64 x86_64 GNU/Linux
[williams@torg ~]$ cat /proc/loadavg*
0.88 0.76 0.57 1/257 7267
122947.70 103790.53 -564712.87 0/257 7267---------->
Fixes spurious system load spikes observed in /proc/loadavgrt, as described in:
Bug 253103: /proc/loadavgrt issues weird results
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253103
---
kernel/sched.c +7 -0
@@ -2520,6 +2520,13 @@ unsigned long rt_nr_uninterruptible(void)for_each_online_cpu (i) sum +=cpu_rq (i)->rt_nr_uninterruptible; +/* +* Since we read the counters lockless, it might be slightly +* inaccurate. Do not allow it to go below zero though: +*/ +if (unlikely ((long )sum <0 )) + sum =0 ; +return sum; }
linux-2.6.21.x86_64_lc/kernel/timer.c renamed from linux-2.6.21.x86_64/kernel/timer.c +8 -6
@@ -1432,23 +1432,25 @@ unsigned long avenrun_rt[3];static inline void calc_load (unsigned long ticks) {unsigned long active_tasks;/* fixed-point */ +unsigned long active_rt_tasks;/* fixed-point */ static int count =LOAD_FREQ ; count -= ticks;if (unlikely (count <0 )) { active_tasks =count_active_tasks (); + active_rt_tasks =count_active_rt_tasks ();do {CALC_LOAD (avenrun[0 ],EXP_1 , active_tasks);CALC_LOAD (avenrun[1 ],EXP_5 , active_tasks);CALC_LOAD (avenrun[2 ],EXP_15 , active_tasks); - count +=LOAD_FREQ ; - }while (count <0 );#ifdef CONFIG_PREEMPT_RT - active_tasks =count_active_rt_tasks (); -CALC_LOAD (avenrun_rt[0 ],EXP_1 , active_tasks); -CALC_LOAD (avenrun_rt[1 ],EXP_5 , active_tasks); -CALC_LOAD (avenrun_rt[2 ],EXP_15 , active_tasks); +CALC_LOAD (avenrun_rt[0 ],EXP_1 , active_tasks); +CALC_LOAD (avenrun_rt[1 ],EXP_5 , active_tasks); +CALC_LOAD (avenrun_rt[2 ],EXP_15 , active_tasks);#endif + count +=LOAD_FREQ ; + + }while (count <0 ); } }
-
Signature · 4 lines
[ Luis Claudio R. Goncalves lclaudio at uudg dot org ] [ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9 2696 7203 D980 A448 C8F8 ] [ Linux-HA Developer - LateNite Programmer - Gospel User - Bass Player ] [ Fault Tolerance - Real-Time - Distributed Systems - IECLB - Is 40:31 ]
Quoted 6 lines · Luis Claudio R. Goncalves
Fixes spurious system load spikes observed in
/proc/loadavgrt, as described in:Bug 253103:
/proc/loadavgrtissues weird results
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253103
It would be nice if you explained better what the code defect was, and how you fixed it .. One could extract that from the code, but it's nice if it's backed up with a text description.. Also you should CC lkml next time.
Daniel
Quoted 10 lines · Daniel Walker
Quoted 4 lines · Luis Claudio R. Goncalves
Fixes spurious system load spikes observed in
/proc/loadavgrt, as described in:Bug 253103:
/proc/loadavgrtissues weird results
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253103It would be nice if you explained better what the code defect was, and how you fixed it .. One could extract that from the code, but it's nice if it's backed up with a text description.. Also you should CC lkml next time.
It would be nice if you'd stop being uber schoolmasterly. Luis explanation of the defect is entirely clear and the resulting fix is obvious. .. You could really look at the patch and figure out your self, that it needs no text description at all. Also you should comment on the nice patch itself next time.
tglx
Quoted 12 lines · Thomas Gleixner
Quoted 10 lines · Daniel Walker
Quoted 4 lines · Luis Claudio R. Goncalves
Fixes spurious system load spikes observed in
/proc/loadavgrt, as described in:Bug 253103:
/proc/loadavgrtissues weird results
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253103It would be nice if you explained better what the code defect was, and how you fixed it .. One could extract that from the code, but it's nice if it's backed up with a text description.. Also you should CC lkml next time.
Quoted 5 lines
It would be nice if you'd stop being uber schoolmasterly. Luis explanation of the defect is entirely clear and the resulting fix is obvious. .. You could really look at the patch and figure out your self, that it needs no text description at all. Also you should comment on the nice patch itself next time.
If all you've said was true I wouldn't have commented on it. There was no text description of the code defect, and yes as I said I can get it from the code but it's _nice_ when it's backed up with a text description ..
If your just going to start flames Thomas take it off list.
Daniel
Quoted 11 lines · Daniel Walker
Quoted 10 lines
Quoted 4 lines
It would be nice if you explained better what the code defect was, and how you fixed it .. One could extract that from the code, but it's nice if it's backed up with a text description.. Also you should CC lkml next time.
It would be nice if you'd stop being uber schoolmasterly. Luis explanation of the defect is entirely clear and the resulting fix is obvious. .. You could really look at the patch and figure out your self, that it needs no text description at all. Also you should comment on the nice patch itself next time.
Quoted 4 lines
If all you've said was true I wouldn't have commented on it. There was no text description of the code defect, and yes as I said I can get it from the code but it's _nice_ when it's backed up with a text description ..
You really start to annoy me. There was a detailed bug description and the code defect is easy to see. If you neither have the interest nor the time to look at the actual _trivial_ _self explaining_ patch, then please look for some other playground to live out your wisenheimer airs and graces.
Quoted 1 line
If your just going to start flames Thomas take it off list.
Flames are only flames when they happen in public.
tglx
Quoted 5 lines · Thomas Gleixner
You really start to annoy me. There was a detailed bug description and the code defect is easy to see. If you neither have the interest nor the time to look at the actual _trivial_
_selfexplaining_patch, then please look for some other playground to live out your wisenheimer airs and graces.
I'm not you, and you can't force your opinion of the code on someone else. _I_ don't think it was trivial .. I really couldn't care less if your annoyed or not ..
Quoted 3 lines
Quoted 1 line
If your just going to start flames Thomas take it off list.
Flames are only flames when they happen in public.
Not really, but either way flames are _bad_ for business.
Daniel
Quoted 11 lines · Daniel Walker
Quoted 5 lines · Thomas Gleixner
You really start to annoy me. There was a detailed bug description and the code defect is easy to see. If you neither have the interest nor the time to look at the actual _trivial_
_selfexplaining_patch, then please look for some other playground to live out your wisenheimer airs and graces.I'm not you, and you can't force your opinion of the code on someone else. _I_ don't think it was trivial .. I really couldn't care less if your annoyed or not ..
Why is it relevant that you are not me ?
I do not force my opinion on someone else, but I simply request that you do not force _your_ rules based on your personal world view on people who send _valid_ and _useful_ patches
Also you as the -rt expert who "releases" his own -rt queues should be able to recognize the value and correctness of such a patch despite the possibly enhanceable text description. If your only comment on such a patch consist of your self defined nitpick rules, then you should go back and read your own mails where you accused others of scaring off developers instead of embracing them.
Keep this tone up and you are right on the way to make the second entry of my kernel related kill file right behind the lonely dude who managed to make it there in 10 years:
http://lkml.org/lkml/2007/4/30/157
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
If your just going to start flames Thomas take it off list.
Flames are only flames when they happen in public.
Not really, but either way flames are _bad_ for business.
I don't have any business with you.
tglx
Quoted 13 lines · Thomas Gleixner
Quoted 11 lines · Daniel Walker
Quoted 5 lines · Thomas Gleixner
You really start to annoy me. There was a detailed bug description and the code defect is easy to see. If you neither have the interest nor the time to look at the actual _trivial_
_selfexplaining_patch, then please look for some other playground to live out your wisenheimer airs and graces.I'm not you, and you can't force your opinion of the code on someone else. _I_ don't think it was trivial .. I really couldn't care less if your annoyed or not ..
Quoted 5 lines
Why is it relevant that you are not me ?
I do not force my opinion on someone else, but I simply request that you do not force _your_ rules based on your personal world view on people who send _valid_ and _useful_ patches
I made a request , and regardless of my own world, what world are you in where a request is described as "force _your_ rules" ..
Quoted 6 lines
Also you as the -rt expert who "releases" his own -rt queues should be able to recognize the value and correctness of such a patch despite the possibly enhanceable text description. If your only comment on such a patch consist of your self defined nitpick rules, then you should go back and read your own mails where you accused others of scaring off developers instead of embracing them.
Again here I make a simple request and I'm "scaring off developers" .. What your doing right now is scaring off developers ..
Quoted 5 lines
Keep this tone up and you are right on the way to make the second entry of my kernel related kill file right behind the lonely dude who managed to make it there in 10 years:
I would have thought I was already there as of two years ago.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
If your just going to start flames Thomas take it off list.
Flames are only flames when they happen in public.
Not really, but either way flames are _bad_ for business.
I don't have any business with you.
Great, then we can end this exchange right now, bye.
Daniel
Quoted 2 lines · Daniel Walker
Again here I make a simple request and I'm "scaring off developers" .. What your doing right now is scaring off developers ..
s/developers/one person who seeks to be scared off/
Quoted 7 lines
Quoted 5 lines
Keep this tone up and you are right on the way to make the second entry of my kernel related kill file right behind the lonely dude who managed to make it there in 10 years:
I would have thought I was already there as of two years ago.
If you would have thought then you would have figured out that you are not in there _yet_.
tglx
Quoted 34 lines · Luis Claudio R. Goncalves
Hello,
The values in
/proc/loadavgrtare sometimes the real load and sometimes garbage. As you can see in th tests below, it occurs from in 2.6.21.5-rt20 to 2.6.23-rc2-rt2. The code forcalc_load(), inkernel/timer.chas not changed much in -rt patches.Signed-off-by Luis Claudio R. Goncalves <[email protected]>---
kernel/sched.c +7
-0@@ -2520,6 +2520,13 @@ unsigned long rt_nr_uninterruptible(void)for_each_online_cpu (i) sum +=cpu_rq (i)->rt_nr_uninterruptible; +/* +* Since we read the counters lockless, it might be slightly +* inaccurate. Do not allow it to go below zero though: +*/ +if (unlikely ((long )sum <0 )) + sum =0 ; +return sum; }linux-2.6.21.x86_64_lc/kernel/timer.c renamed from linux-2.6.21.x86_64/kernel/timer.c +0
-0
linux-2.6.21.x86_64_lc/kernel/timer.c unsigned long avenrun_rt[3]; · line 1441
Quoted 10 lines
linux-2.6.21.x86_64_lc/kernel/timer.c renamed from linux-2.6.21.x86_64/kernel/timer.c +2
-0@@ -1432,23 +1432,25 @@ unsigned long avenrun_rt[3];static inline void calc_load (unsigned long ticks) {unsigned long active_tasks;/* fixed-point */ +unsigned long active_rt_tasks;/* fixed-point */ static int count =LOAD_FREQ ; count -= ticks;if (unlikely (count <0 )) { active_tasks =count_active_tasks (); + active_rt_tasks =count_active_rt_tasks ();
Where is this used?
Quoted 41 lines · Sven-Thorsten Dietrich
Quoted 40 lines · Luis Claudio R. Goncalves
Hello,
The values in
/proc/loadavgrtare sometimes the real load and sometimes garbage. As you can see in th tests below, it occurs from in 2.6.21.5-rt20 to 2.6.23-rc2-rt2. The code forcalc_load(), inkernel/timer.chas not changed much in -rt patches.Signed-off-by Luis Claudio R. Goncalves <[email protected]>---
kernel/sched.c +7
-0@@ -2520,6 +2520,13 @@ unsigned long rt_nr_uninterruptible(void)for_each_online_cpu (i) sum +=cpu_rq (i)->rt_nr_uninterruptible; +/* +* Since we read the counters lockless, it might be slightly +* inaccurate. Do not allow it to go below zero though: +*/ +if (unlikely ((long )sum <0 )) + sum =0 ; +return sum; }linux-2.6.21.x86_64_lc/kernel/timer.c renamed from linux-2.6.21.x86_64/kernel/timer.c +1
-0@@ -1432,23 +1432,25 @@ unsigned long avenrun_rt[3];static inline void calc_load (unsigned long ticks) {unsigned long active_tasks;/* fixed-point */ +unsigned long active_rt_tasks;/* fixed-point */ static int count =LOAD_FREQ ;
Quoted 6 lines
linux-2.6.21.x86_64_lc/kernel/timer.c unsigned long avenrun_rt[3]; · line 1441
Quoted 4 lines
linux-2.6.21.x86_64_lc/kernel/timer.c renamed from linux-2.6.21.x86_64/kernel/timer.c +1
-0count -= ticks;if (unlikely (count <0 )) { active_tasks =count_active_tasks (); + active_rt_tasks =count_active_rt_tasks ();Where is this used?
what is "this"? /proc/loadavg? Or the code/patch you quoted?
Ingo
Quoted 43 lines · Ingo Molnar
Quoted 41 lines · Sven-Thorsten Dietrich
Quoted 40 lines · Luis Claudio R. Goncalves
Hello,
The values in
/proc/loadavgrtare sometimes the real load and sometimes garbage. As you can see in th tests below, it occurs from in 2.6.21.5-rt20 to 2.6.23-rc2-rt2. The code forcalc_load(), inkernel/timer.chas not changed much in -rt patches.Signed-off-by Luis Claudio R. Goncalves <[email protected]>---
kernel/sched.c +7
-0@@ -2520,6 +2520,13 @@ unsigned long rt_nr_uninterruptible(void)for_each_online_cpu (i) sum +=cpu_rq (i)->rt_nr_uninterruptible; +/* +* Since we read the counters lockless, it might be slightly +* inaccurate. Do not allow it to go below zero though: +*/ +if (unlikely ((long )sum <0 )) + sum =0 ; +return sum; }linux-2.6.21.x86_64_lc/kernel/timer.c renamed from linux-2.6.21.x86_64/kernel/timer.c +1
-0@@ -1432,23 +1432,25 @@ unsigned long avenrun_rt[3];static inline void calc_load (unsigned long ticks) {unsigned long active_tasks;/* fixed-point */ +unsigned long active_rt_tasks;/* fixed-point */ static int count =LOAD_FREQ ;
Quoted 8 lines
Quoted 6 lines
linux-2.6.21.x86_64_lc/kernel/timer.c unsigned long avenrun_rt[3]; · line 1441
Quoted 4 lines
linux-2.6.21.x86_64_lc/kernel/timer.c renamed from linux-2.6.21.x86_64/kernel/timer.c +1
-0count -= ticks;if (unlikely (count <0 )) { active_tasks =count_active_tasks (); + active_rt_tasks =count_active_rt_tasks ();Where is this used?
what is "this"?
/proc/loadavg? Or the code/patch you quoted?
active_rt_tasks
Quoted 2 lines
Ingo
On Thu, Aug 23, 2007 at 08:57:32AM -0700, Sven-Thorsten Dietrich wrote:
| On Thu, 2007-08-23 at 17:51 +0200, Ingo Molnar wrote: | > * Sven-Thorsten Dietrich <[email protected]> wrote: | > | > > On Thu, 2007-08-16 at 21:37 -0300, Luis Claudio R. Goncalves wrote: | > > > Hello, | > > > | > > > The values in /proc/loadavgrt are sometimes the real load and sometimes | > > > garbage. As you can see in th tests below, it occurs from in 2.6.21.5-rt20 | > > > to 2.6.23-rc2-rt2. The code for calc_load(), in kernel/timer.c has not | > > > changed much in -rt patches. ... | > > > active_tasks = count_active_tasks(); | > > > + active_rt_tasks = count_active_rt_tasks(); | > > | > > Where is this used? | > | > what is "this"? /proc/loadavg? Or the code/patch you quoted? | | active_rt_tasks
Good point! I misspelled it in my first patch.
This one should be better!
---------->
Fixes spurious system load spikes observed in /proc/loadavgrt, as described in:
Bug 253103: /proc/loadavgrt issues weird results
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253103
---
kernel/sched.c +7 -0
@@ -2520,6 +2520,13 @@ unsigned long rt_nr_uninterruptible(void)for_each_online_cpu (i) sum +=cpu_rq (i)->rt_nr_uninterruptible; +/* +* Since we read the counters lockless, it might be slightly +* inaccurate. Do not allow it to go below zero though: +*/ +if (unlikely ((long )sum <0 )) + sum =0 ; +return sum; }
kernel/timer.c +8 -6
@@ -1432,23 +1432,25 @@ unsigned long avenrun_rt[3];static inline void calc_load (unsigned long ticks) {unsigned long active_tasks;/* fixed-point */ +unsigned long active_rt_tasks;/* fixed-point */ static int count =LOAD_FREQ ; count -= ticks;if (unlikely (count <0 )) { active_tasks =count_active_tasks (); + active_rt_tasks =count_active_rt_tasks ();do {CALC_LOAD (avenrun[0 ],EXP_1 , active_tasks);CALC_LOAD (avenrun[1 ],EXP_5 , active_tasks);CALC_LOAD (avenrun[2 ],EXP_15 , active_tasks); - count +=LOAD_FREQ ; - }while (count <0 );#ifdef CONFIG_PREEMPT_RT - active_tasks =count_active_rt_tasks (); -CALC_LOAD (avenrun_rt[0 ],EXP_1 , active_tasks); -CALC_LOAD (avenrun_rt[1 ],EXP_5 , active_tasks); -CALC_LOAD (avenrun_rt[2 ],EXP_15 , active_tasks); +CALC_LOAD (avenrun_rt[0 ],EXP_1 , active_rt_tasks); +CALC_LOAD (avenrun_rt[1 ],EXP_5 , active_rt_tasks); +CALC_LOAD (avenrun_rt[2 ],EXP_15 , active_rt_tasks);#endif + count +=LOAD_FREQ ; + + }while (count <0 ); } }
-