Re: [PATCH] irq_balance does not make sense with HT but single physicalCPU

From: Kai Bankett
Date: Wed Nov 26 2003 - 11:31:07 EST


Zwane Mwaikambo wrote:

On Wed, 26 Nov 2003, Kai Bankett wrote:

this patch should disable irq_balance threat in case of only one
installed physical cpu thats running in HyperThreading-mode (so reported
as 2 cpus).
I think it should make no sense to run irq_blanance in that special case
- please correct me if i´m wrong.


+#ifdef CONFIG_X86_HT
+ /* On Hyper-Threading CPUs - if only one physical installed
+ balance does not make sense */
+ if (cpu_has_ht && smp_num_siblings == 2 && num_online_cpus() == 2) {
+ irqbalance_disabled = 1;
+ return 0;
+ }
+#endif

Further down, i believe the following would have the same effect;

/*
* Enable physical balance only if more than 1 physical processor
* is present
*/
if (smp_num_siblings > 1 && !cpus_empty(tmp))
physical_balance = 1;


tmp = cpu_online_map >> 2;

so we drop the first two processors (logical or physical) and only enable
physical balance if there are still processors present in the map. Or are
you observing something else?


Ok - inserted an printk(smp_num_siblings) to have a look into smp_num_siblings at that point.

It says : smp_num_siblings = 2

But anyways if physical_balance is set to 1 that won´t prevent anything from running through/sleeping in the kernel_thread-loop.
The kernel_thread(balance_irq ...) later on will be started/will run not matter what physical_balance says.

Do there exist any cases where smp_siblings are created without HyperThreading ? (As far as I remember it´s only incremented/used on i386 hyperthreaded architectures - but not 100% sure)

-> At least the if has to look like :

...
if (smp_num_siblings > 2 && !cpus_empty(tm))
physical_balance = 1;
...

(if - like in my case - smp_num_siblings == 2 on a single P4 system)

That one still does not solve the case in which the kernel_thread is not needed and only eats resources.
Of course - maybe the whole thing can be merged together. Not sure about that. But source will become more complex in that case - k.i.s.s. may be the better approach.

Thanks,

Kai

--
--------------------------------------------
Kai Bankett
Network Engineering

AOL Deutschland GmbH & Co. KG

Millerntorplatz 1
20359 Hamburg
Tel.: +49 40 36159 - 7559
Fax.: +49 40 36159 - 7510
Mobil: +49 172 2353870
eMail to kbankett@xxxxxxx
AIM: kbankett
--------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/