QA (public) » openQA Project (public) » openQA Tests (public)

Christian, would be nice to have some update from you every 2-3 days, so other team members could easier help you if needed.

Current Status:

What I found out
HT has been implemented in release 2.4.17. It has been handled as sort of SMP which means that it got displayed as there would have been many sockets instead of one socket with two logical threads per core.
With release 2.6.X (tbd) the whole thing changed. Now /proc/cpuinfo shows a physical id per socket, a core id for each core on the socket and a "processor" which means the logical processor id.
So when the program checks for HT before executing the test it always returns false because of this instability of /proc/cpuinfo.

The check works as follows:

1. Check whether the Kernel is capable to run HT.
2. Check whether the CPU is capable of HT.
3. Check whether HT is actually enabled.

This does make much sense so far. But I have some doubts:

1. I think it would be better to determine whether the Kernel is capable of HT by the version > 2.4.17 instead of a string in /proc/cpuinfo.
2. I can't complain about the way how the check for the capability of the CPU is made.
3. TBD: I think I should determine whether the current way to check for HT to be enabled covers all cases or whether there are cases when a logical vs physical core count of 2:1 is displayed although HT has been disabled by a kernel boot parameter for example. Probably there are cases that should be included.

What I have started to code so far:
Is retrieving the release version of the kernel where the test suite is executed in order to have a more reliable way to check for HT capability. And because my experience with C is more basic I had to look up some things to make progress with this first stage of the whole checking routine.

There is a corresponding issue on LTP git bugtracker:
https://github.com/linux-test-project/ltp/issues/211

Update

All three checks don't work. I have fixed the check for an HT capable kernel determining it by the release version >2.4.17. Skipping these checks and just running the test seems to result in a fail with less cores but passed on a VM with many cores. I have looked into kernel sources to learn how they retrieve several information.

HT being just Intel's implementation of SMT it looks questionable to me whether it makes that much sense to have this test for HT which would restrict the number of threads per core to 2 while there are processors like the Power processors of IBM that can run in SMT mode with up to 8 threads. Testing for a ratio of 2 threads per core is one of the key elements in the current checks whether HT is enabled.
I think I should find out how supported CPU architectures advertise their capabilities for SMT and if it's possible to combine the tests.

It looks very much like the current kernel versions only provide file sockets for setting the processor affinity of the IRQ IDs in /proc/irq/ . These are used by the userspace daemon irqbalance.
According to this commit message the IRQ balancing ability of the kernel has been removed in October 2008:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=8b8e8c1bf7275eca859fe551dfa484134eaf013b

The commit message is probably a bit irritating because it is only about 32 bit systems. But in the corresponding 64 bit files I haven't found the content that was removed in order to remove IRQ balancing at all.
I have also searched for other hints of a new implementation of IRQ balancing and so on but haven't found any.
HT capability was introduced with 2.4.17 and the IRQ balancing seems to have been removed with some release number like ~ 2.6.29. I haven't found out yet when IRQ balancing was introduced but probably not directly with 2.4.17. That would mean the HT_interrupt test would be obsolete for almost every Kernel.

As far as I understand correctly when interrupts are distributed decently on all available or at least several (logical) processors it can increase the overall performance and decrease the response latency for interrupts. But on the other hand real time applications will have increased latency when the interrupt is set to target their assigned processor.
So the ht_interrupt test is mainly focused on the performance of the kernel with ht in specific situations. That means there are no severe issues to be expected when the interrupts will target specific processors.

In my opinion, when all the information I gathered is correct the ht_interrupt test could be removed or tested and adapted to just run for these specific release versions when it's worth it.

In my opinion, when all the information I gathered is correct the ht_interrupt test could be removed or tested and adapted to just run for these specific release versions when it's worth it.

I think removing it would be a good idea.

Maybe we should have a test which checks that setting the IRQ affinity works (if we do not have one already), but that would be a separate task.

Thanks for your reply Richard,

we have smt_smp_affinity and smt_smp_enabled in the hyperthreading folder. Both seem to run fine on my machine. So I will prepare a PR that deletes the ht_interrupt files.