On Wed, Oct 17, 2018 at 10:48 AM, Bart Van Assche <bvanassche@xxxxxxx> wrote: > On 10/17/18 3:05 AM, Jan Kara wrote: >> >> Well, the problem with this is that big distro people really don't care >> much because they already use udev for tuning the IO scheduler. So >> whatever >> defaults the kernel is going to pick likely won't be seen by distro >> customers. Embedded people seem to be driving this effort because they >> either don't run udev or they feel not all their teams building new >> products have enough expertise to come up with a proper set of rules... > > > What's missing in this discussion is a definition of "embedded system". Is > that a system like a streaming player for TV channels that neither has a > keyboard nor a display or a system that can run multiple apps simultaneously > like a smartphone? I think the difference matters because some embedded > devices hardly do any background I/O nor load any executable code from > storage after boot. So at least for some embedded devices the problem > discussed in this e-mail thread does not exist. > > Bart. There are high-performance embedded systems on the market (NAS, etc.). I feel strongly about the prevention of users running into errors because of an incorrect scheduler default, because I encountered that situation three times in my testing with zoned block devices. The switch to SCSI_MQ would resolve that, since mq-deadline is the default, but in my case, I was using Fedora 28, which disables CONFIG_SCSI_MQ_DEFAULT (which is enabled in the 4.18 kernel), so my default scheduler was cfq. Hopefully there aren't any other cases where choosing the "wrong default scheduler" leads to errors. Ideally the default scheduler choice should prevent any errors, leaving it up to the distros to configure a default via other methods, to optimize for performance. Thanks, Bryan
