On Fri July 31 2009, Andi Kleen wrote: > Andreas Mohr <andi@xxxxxxxx> writes: > > > 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). > > The interrupt heuristics in the menu cpuidle governour are already > attempting this, based on interrupt rates (or rather > wakeup rates) which are supposed to roughly correspond with IO rates > and scheduling events together. > > Apparently that doesn't work in this case. The challenge would > be to find out why and improve the menu algorithm to deal with it. > I doubt a completely new mechanism is needed or makes sense. > > > 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) > > This is already done. > Almost - the VIA C7-M needs a bit of kernel command line help - - But should be easily fixable when I or one of the VIA support people GATI. (Bus snoops are only fully supported in C0 and C1 but idle=halt takes care of that.) Mike > -Andi -- 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
