On Wed, Jul 8, 2015 at 7:00 AM, Martin Møller Skarbiniks Pedersen <[email protected]> wrote: > Hi, > Under Objectives 204.2 it says: > "Tools and utilities to configure DMA for IDE devices including ATAPI and > SATA" > Is DMA configuration for IDE devices really needed in 2015 ? > Maybe it should be removed.
PIO is still actually in use [1a], _but_ I agree with you portions of section 204 need to be updated. I would argue (i.e., opinion) we might want to step back and "modernize" the section and focus on two (2) different host controller architectures: - AHCI (with IDE compatibility [1b]) - NVMe We need to get away from traditional ATA-centric nomenclature, as the even the mainstream world will soon be experiencing an explosion of NVMe. It's happening this year, as kernel support was added late 2.6.x series. I.e., don't focus on SATA v. SATA Express v. eMMC, etc..., but focus on the controller interfaces that the OS cares about -- especially boot. E.g., AHCI and NVMe are completely _different_ and _incompatible_ from the standpoint of Linux kernel boot, device support, etc... For boot compatibility, we've just emulated AHCI for EEPROM -- even when direct PCIe peripheral interconnect is used instead of an ATA controller -- which is grossly inefficient for commanding/queuing for EEPROM. I.e., throughput is _not_ the main advantage of EEPROM [2a], especially for reads (writes are actually much slower [2b], and very power costly, despite popular assumption [2c]), but latency. [2a] Additionally for section 204 ... We also want to be including the tools that leverage the /sys tree. [3] I.e., storage information under /sys/block is already loaded and what the kernel sees and thinks exists, plus doesn't require superuser privilege to view. E.g., include the lsblk command that virtually every distro has had for a long time. -- bjs [1a] PIO is still supported in AHCI, especially for select end-point communication. Furthermore, despite popular assumption, the SATA controller can be reconfigured to use PIO, because -- again -- it already does some PIO. I know this gets confusing, because the host-to-controller bus should always be DMA, but there can be cases where the controller-to-endpoint link has dropped to PIO, because the DMA error rates on the link are extremely high. Some OSes will reconfigure the SATA controller to drop to PIO, other OSes will just take the link off-line instead, rendering the device unavailable -- not always ideal, and yes, Linux does this, hence the reason why PIO should still be covered. [1b] eMMC also makes use of PIO, and is also backward compatible with IDE mode, in addition to AHCI. eMMC is popular for even low-end PC portables which are running generic OSes more and more. I.e., it's only getting more popular these days because it's consumer replaceable. We'll see if eMMC goes NVMe at some point, as 4-bit Secure-Digital transfers are [2a] EEPROM read access times are several magnitudes faster than platter, with writes only a couple (more in [2b]). This is where the "throughput" seems to come from. But in reality, AHCI has extremely limited commanding and queuing, a single handful, for platter endpoints, whereas EEPROM can have hundreds, even thousands (not so commodity) in flight, drastically improving latency even further, and "keeping the link utilized." Especially given ... [2b] Common consumer NAND EEPROM has massive amounts of DRAM in them these days. These are _required_ to buffer the much slower writes (than reads). This is why most higher-capacity NAND EEPROM devices perform so well than even their lower capacities, because they have 0.5-1MiB DRAM for every 1GB NAND cells. So there is not only a lot of built-in buffer, but that buffer is also read cache (of things recently written, or at least commonly loaded), which could be commanded almost like RAM. The downsize of all that RAM is power and non-volitality. Hence ... [2c] Consumer NAND devices of 256GB-1TB are now sucking down 2A+ (even 3A) at 5V, which is 4x (and even 6x) more than a 2.5" platter drive, despite common assumption. This is also why external closures, powered only by USB, don't work with most NAND devices in them these days, hence the common, "Help! I cannot get my SSD to work in any external eSATA / USB 3.0 enclosure!" It also means that other than a little bit of stored capacitance, if your computer "crashes," you should _always_ and _immediately_ power _back_on_ to flush any writes in the DRAM buffer before the constantly required refresh of DRAM cells discharges all of the limited capacitance. Data journaling, especially meta-data journaling, does _not_ address this well, despite common assumptions (don't get me started on the state diagram). [3] There are an increasing number of ls* utilities that pull information out of /sys as well, removing the need for any privilege. Some return additional info if the user has superuser privilege, but still work without it. We should update sections to include them as they appear in popular distros. _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
