Messages in this thread | | | Date | Thu, 06 Mar 2003 14:22:48 -0800 | From | "Martin J. Bligh" <> | Subject | Re: HT and idle = poll |
| |
> 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.
BTW, could someone give a brief summary of why idle=poll is needed for oprofile, I'd love to add it do the "documentation for dummies" file I was writing.
M.
- 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/
| |