Hello, Mark Lord wrote: >> One thing I don't understand about this argument is that PIO cycle time >> is not determined by CPU power. It's bound by PCI and ATA bus speed. >> If you put a faster CPU on the job, it just ends up wasting the same >> amount of time burning up more CPU cycles or am I misjudging power of >> those embedded CPUs? > ... > > Yes, it wastes the same amount of real (clock on the wall) time. > > But since it is typically a much slower system to begin with, > it has little in the way of "excess" computing capability, > so those few hundred microseconds of PIO time mean a lot > more to it than they would to a GHz+ processor. > > In other words, such devices are usually close to their real-time > limits to begin with, so a 200-300usec real-time delay is difficult > to "make up" afterwards. > > For a 1.8GHz Pentium-M, no problem --> it can churn away about > 2-3 thousand instructions per microsecond afterwards. > > But an 800MHz geode would require 2-8X that amount of real time > to execute the same number of "catch up" instructions. Okay, that makes more sense. The only thing which happens regularly is polling for media change which involves reading maybe a few tens of bytes. The overhead of doing those using PIO wouldn't be too much more than the cost of writing CDBs out. It would help more if we can cut down the number of commands used for testing media changed event (on my to do list). During probing, it doesn't really matter. The only other case where many of these misc ATAPI commands can occur is when new media is inserted and starting up writing. And yeah I can see it might hurt if the processor is already fully loaded. > If I were doing this, I'd probably just do PIO for all non bulk xfer > opcodes, same as you, for ease of maintainership. > > But I'd also think really hard about some way to allow full DMA > for chipsets/drives that can be trusted. Not a whitelist (like Alan, > I don't believe in those), but something.. Does module parameter / sysfs node sound good enough to you? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
