Messages in this thread | | | Date | Wed, 23 Apr 2003 05:17:05 -0400 (EDT) | From | Ingo Molnar <> | Subject | Re: several messages |
| |
On Tue, 22 Apr 2003, Rick Lindsley wrote:
> True. I have a hunch (and it's only a hunch -- no hard data!) that two > threads that are sharing the same data will do better if they can be > located on a physical/sibling processor group. For workloads where you > really do have two distinct processes, or even threads but which are > operating on wholly different portions of data or code, moving them to > separate physical processors may be warranted. The key is whether the > work of one sibling is destroying the cache of another.
If two threads have a workload that wants to be co-scheduled then the SMP scheduler will do damage to them anyway - independently of any HT scheduling decisions. One solution for such specific cases is to use the CPU-binding API to move those threads to the same physical CPU. If there's some common class of applications where this is the common case, then we could start thinking about automatic support for them.
Ingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |