On 2011-09-01 14:27, Werner Fischer wrote: >> One note on that - this mode is going >> away in the future. > Do you mean that this mode is going away in the future for the Fusion-io > driver or that generally no driver will be able to hook in there (also > the mtip32xx and nvmhci-express drivers you mention below)? For this particular case, I meant the fusion-io driver. Even for the current 2.x series of the driver, bypassing the IO scheduler is not the default. You have to manually specify that with a module option. >> You end up losing out on request merging, so write >> performance is hampered, for one. >> >> The Micron pci-e mtip32xx driver does similarly, as does the >> nvmhci-express driver from Intel. IMHO it's largely due to >> inefficiencies in the IO stack, once we get those fixed, we should be >> getting back to the one true single IO mode for a driver. > With "one true single IO mode for a driver" you mean that every device > driver should sit and stay below the I/O scheduler? > Or do you mean that there should only be one single I/O scheduler? (in > the patch removing the anticipatory scheduler you suggested something > like this: > http://git.kernel.org/linus/492af6350a5ccf087e4964104a276ed358811458 ) I mean that every device should plug in at the same place. There are definite up and down sides to plugging in at the stacking level and bypassing the IO scheduler. So you have to weight the pros and cons before doing that. We need to fix this. Drivers doing that lose out on other features in the name of a bit more performance, that's just not acceptable. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
