Hi,
Next patch provides a CPU_THRESHOLD; makes sense since we also have a NODE_THRESHOLD as tuning knob.
Frank.
sched.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff -Nru a/kernel/sched.c b/kernel/sched.c
--- a/kernel/sched.c Fri Aug 22 14:20:23 2003
+++ b/kernel/sched.c Fri Aug 22 14:20:23 2003
@@ -76,6 +76,7 @@
#define MAX_SLEEP_AVG (10*HZ)
#define STARVATION_LIMIT (10*HZ)
#define NODE_THRESHOLD 125
+#define CPU_THRESHOLD 75
/*
* If a task is 'interactive' then we reinsert it in the active
@@ -963,10 +964,9 @@
if (likely(!busiest))
goto out;
- *imbalance = (max_load - nr_running) / 2;
+ *imbalance = (max_load - nr_running) >> 1;
- /* It needs an at least ~25% imbalance to trigger balancing. */
- if (!idle && (*imbalance < (max_load + 3)/4)) {
+ if (!idle && (*imbalance*100 < nr_running*CPU_THRESHOLD)) {
busiest = NULL;
goto out;
}
hello Frank,
> - *imbalance = (max_load - nr_running) / 2;
> + *imbalance = (max_load - nr_running) >> 1;
I think it is a good coding practice to keep things human-readable.
In this code snippet, the division by 2 is quickly understood by most
readers (specially those who didn't write it). The right shift may
obfuscate the real meaning of this operation, which is a single
division by 2, not a bit-oriented expression.
Assuming that sched.c will be compiled with optimizations enabled, the
compiler will change the human-readable division by a fast machine
right shift operation, whenever possible (gcc surely will).
Thus, we keep the kernel code more readable, and sometimes let the
compiler apply newer (and hopefully faster) optimizations than some
tricks we have known as fastest available.
Regards, and please let me know what do you think about it.
--
Ricardo Nabinger Sanchez
GNU/Linux #140696 [http://counter.li.org]
Slackware Linux
Ricardo Nabinger Sanchez wrote:
> hello Frank,
>
>
>>- *imbalance = (max_load - nr_running) / 2;
>>+ *imbalance = (max_load - nr_running) >> 1;
>
>
> I think it is a good coding practice to keep things human-readable.
> In this code snippet, the division by 2 is quickly understood by most
> readers (specially those who didn't write it). The right shift may
> obfuscate the real meaning of this operation, which is a single
> division by 2, not a bit-oriented expression.
>
> Assuming that sched.c will be compiled with optimizations enabled, the
> compiler will change the human-readable division by a fast machine
> right shift operation, whenever possible (gcc surely will).
>
> Thus, we keep the kernel code more readable, and sometimes let the
> compiler apply newer (and hopefully faster) optimizations than some
> tricks we have known as fastest available.
>
> Regards, and please let me know what do you think about it.
>
Note that right-shift rounds towards negative infinity, while divide
rounds towards zero.
If the operands are unsigned, then rsh and divide will yield the same
instructions (on x86). OTOH, if they are signed, then you get different
results. For this rsh, obviously, you get a shift, but for divide, you
get something like this:
; divide edx by 2
mov ecx,edx
lsr ecx,31
asr edx,1
add edx,ecx