[PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Luis Claudio R. Goncalves]

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

Signed-off-by: Luis Claudio R. Goncalves <lclaudio@uudg.org>
---

diff --git a/kernel/sched.c b/kernel/sched.c
index 811a502..c61609a 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -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;
 }
 
diff --git a/linux-2.6.21.x86_64/kernel/timer.c b/linux-2.6.21.x86_64_lc/kernel/timer.c
index 882ca9d..0e49bf6 100644
--- a/linux-2.6.21.x86_64/kernel/timer.c
+++ b/linux-2.6.21.x86_64_lc/kernel/timer.c
@@ -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);
 	}
 }
 
-
-- 
[ 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 ]

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Daniel Walker]

On Thu, 2007-08-16 at 21:37 -0300, Luis Claudio R. Goncalves wrote:

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


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

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Thomas Gleixner]

On Thu, 2007-08-16 at 20:58 -0700, Daniel Walker wrote:
> On Thu, 2007-08-16 at 21:37 -0300, Luis Claudio R. Goncalves wrote:
> > 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
>
> 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.

	tglx

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Daniel Walker]

On Fri, 2007-08-17 at 10:39 +0200, Thomas Gleixner wrote:
> On Thu, 2007-08-16 at 20:58 -0700, Daniel Walker wrote:
> > On Thu, 2007-08-16 at 21:37 -0300, Luis Claudio R. Goncalves wrote:
> > > 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
> >
> > 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.

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

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Thomas Gleixner]

On Fri, 2007-08-17 at 09:24 -0700, Daniel Walker wrote:
> > > 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.
> 
> 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.

> If your just going to start flames Thomas take it off list.

Flames are only flames when they happen in public.

	tglx

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Daniel Walker]

On Fri, 2007-08-17 at 23:37 +0200, Thomas Gleixner wrote:

> 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.

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 .. 

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

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Thomas Gleixner]

On Fri, 2007-08-17 at 14:43 -0700, Daniel Walker wrote:
> On Fri, 2007-08-17 at 23:37 +0200, Thomas Gleixner wrote:
> 
> > 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.
> 
> 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

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

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Daniel Walker]

On Sat, 2007-08-18 at 00:21 +0200, Thomas Gleixner wrote:
> On Fri, 2007-08-17 at 14:43 -0700, Daniel Walker wrote:
> > On Fri, 2007-08-17 at 23:37 +0200, Thomas Gleixner wrote:
> > 
> > > 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.
> > 
> > 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

I made a request , and regardless of my own world, what world are you in
where a request is described as "force _your_ rules" ..

> 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 ..

> 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

I would have thought I was already there as of two years ago.

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

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Thomas Gleixner]

On Fri, 2007-08-17 at 15:43 -0700, Daniel Walker wrote:
> 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/

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

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Sven-Thorsten Dietrich]

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.

> 
> Signed-off-by: Luis Claudio R. Goncalves <lclaudio@uudg.org>
> ---
> 
> diff --git a/kernel/sched.c b/kernel/sched.c
> index 811a502..c61609a 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -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;
>  }
>  
> diff --git a/linux-2.6.21.x86_64/kernel/timer.c b/linux-2.6.21.x86_64_lc/kernel/timer.c
> index 882ca9d..0e49bf6 100644
> --- a/linux-2.6.21.x86_64/kernel/timer.c
> +++ b/linux-2.6.21.x86_64_lc/kernel/timer.c
> @@ -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?

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Ingo Molnar]

* Sven-Thorsten Dietrich <sven@thebigcorporation.com> 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.
> 
> > 
> > Signed-off-by: Luis Claudio R. Goncalves <lclaudio@uudg.org>
> > ---
> > 
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index 811a502..c61609a 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -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;
> >  }
> >  
> > diff --git a/linux-2.6.21.x86_64/kernel/timer.c b/linux-2.6.21.x86_64_lc/kernel/timer.c
> > index 882ca9d..0e49bf6 100644
> > --- a/linux-2.6.21.x86_64/kernel/timer.c
> > +++ b/linux-2.6.21.x86_64_lc/kernel/timer.c
> > @@ -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?

what is "this"? /proc/loadavg? Or the code/patch you quoted?

	Ingo

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Sven-Thorsten Dietrich]

On Thu, 2007-08-23 at 17:51 +0200, Ingo Molnar wrote:
> * Sven-Thorsten Dietrich <sven@thebigcorporation.com> 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.
> > 
> > > 
> > > Signed-off-by: Luis Claudio R. Goncalves <lclaudio@uudg.org>
> > > ---
> > > 
> > > diff --git a/kernel/sched.c b/kernel/sched.c
> > > index 811a502..c61609a 100644
> > > --- a/kernel/sched.c
> > > +++ b/kernel/sched.c
> > > @@ -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;
> > >  }
> > >  
> > > diff --git a/linux-2.6.21.x86_64/kernel/timer.c b/linux-2.6.21.x86_64_lc/kernel/timer.c
> > > index 882ca9d..0e49bf6 100644
> > > --- a/linux-2.6.21.x86_64/kernel/timer.c
> > > +++ b/linux-2.6.21.x86_64_lc/kernel/timer.c
> > > @@ -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?
> 
> what is "this"? /proc/loadavg? Or the code/patch you quoted?

active_rt_tasks

> 
> 	Ingo

Re: [PATCH] Fixes spurious system load spikes in /proc/loadavgrt

[Luis Claudio R. Goncalves]

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 <sven@thebigcorporation.com> 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

Signed-off-by: Luis Claudio R. Goncalves <lclaudio@uudg.org>
---

diff --git a/kernel/sched.c b/kernel/sched.c
index 811a502..c61609a 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -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;
 }
 
diff --git a/kernel/timer.c b/kernel/timer.c
index 882ca9d..0e49bf6 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -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);
 	}
 }
 
-
--