Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: HT and idle = poll | Date | Thu, 6 Mar 2003 19:30:42 +0000 (UTC) |
| |
In article <200303052318.04647.habanero@us.ibm.com>, Andrew Theurer <habanero@us.ibm.com> wrote: >The test: kernbench (average of kernel compiles5) with -j2 on a 2 physical/4 >logical P4 system. This is on 2.5.64-HTschedB3: > >idle != poll: Elapsed: 136.692s User: 249.846s System: 30.596s CPU: 204.8% >idle = poll: Elapsed: 161.868s User: 295.738s System: 32.966s CPU: 202.6% > >A 15.5% increase in compile times. > >So, don't use idle=poll with HT when you know your workload has idle time! I >have not tried oprofile, but it stands to reason that this would be a >problem. There's no point in using idle=poll with oprofile and HT anyway, as >the cpu utilization is totally wrong with HT to begin with (more on that >later). > >Presumably a logical cpu polling while idle uses too many cpu resources >unnecessarily and significantly affects the performance of its sibling.
Btw, I think this is exactly what the new HT prescott instructions are for: instead of having busy loops polling for a change in memory (be it a spinlock or a "need_resched" flag), new HT CPU's will support a "mwait" instruction.
But yes, at least for now, I really don't think you should really _ever_ use "idle=poll" on HT-enabled hardware. The idle CPU's will just suck cycles from the real work.
Linus - 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/
| |