Hi, On Fri, Jul 31, 2009 at 03:06:46PM +0800, Zhang, Yanmin wrote: > On Thu, 2009-07-30 at 21:43 -0600, Robert Hancock wrote: > > On 07/28/2009 04:11 AM, Andreas Mohr wrote: > > > Oh, and about the places which submit I/O requests where one would have to > > > flag this: are they in any way correlated with the scheduler I/O wait > > > value? Would the I/O wait mechanism be a place to more easily and centrally > > > indicate that we're waiting for a request to come back in "very soon"? > > > OTOH I/O requests may have vastly differing delay expectations, > > > thus specifically only short-term expected I/O replies should be flagged, > > > otherwise we're wasting lots of ACPI deep idle opportunities. > > > > Did the results show a big difference in performance between maximum C2 > > and maximum C3? > No big difference. I tried different max cstate by processor.max_cstate. > Mostly, processor.max_cstate=1 could get the similiar result like idle=poll. OK, but I'd say that this doesn't mean that we should implement a hard-coded mechanism which simply says "in such cases, don't do anything > C1". Instead we should strive for a far-reaching _generic_ mechanism which gathers average latencies of various I/O activities/devices and then uses some formula to determine the maximum (not necessarily ACPI) idle latency that we're willing to endure (e.g. average device I/O reply latency divided by 10 or so). And in addition to this, we should also take into account (read: skip) any idle states which kill busmaster DMA completely (in case of busmaster DMA I/O activities, that is). _Lots_ of very nice opportunities for improvement here, I'd say... (in the 5, 10 or even 40% range in the case of certain network I/O) Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
