lkml.org 
[lkml]   [2018]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] block: BFQ default for single queue devices
    On Wed, Oct 3, 2018 at 1:49 PM Oleksandr Natalenko
    <oleksandr@natalenko.name> wrote:

    > On another hand, the users of embedded devices, mentioned by Linus,
    > should already know what scheduler to choose because dealing with
    > embedded world assumes the person can decide this on their own, or with
    > the help of abovementioned udev scripts and/or Documentation/ as a
    > reference point.
    >
    > So I see no obstacles here, and the choice to rely on udev by default
    > sounds reasonable.

    I am sorry but I do not agree with this.

    There are several historical precedents where we have
    concluded that just "have the kernel do the right thing
    by default" is the way to go.

    Example 1: pluggable CPU schedulers.
    The reasoning was that users or distros have no clue what
    scheduler they want, only scheduler developers do. We
    drove it to the point where we have one and one
    scheduler only, not different flavors. (Special
    usecases have special scheduling classes inside the
    one scheduler instead.)

    Example 2: Automatic process group scheduling
    The reasoning was that daemons such as systemd would
    be better at placing processes/tasks into the right
    control groups to manage their resources, so this would
    be a userspace policy handled by the udev/systemd
    complex. We did not do that. Instead the kernel does
    autogrouping per-session, indeed it is a Kconfig option
    but even e.g. Fedora has this enabled by default.
    (commit 5091faa449ee)

    As pointed out elsewhere: these defaults make it
    easy for custom builds not using udev+systemd to
    get a system up and running with sensible defaults.

    Simple embedded systems use Busybox' mdev (I wouldn't
    trust it do do any complex decisions). OpenWRT
    has ubox+ubus+uci, also extremely lightweight,
    Android has its own init system that I don't
    manage to keep track of anymore. Instead of running
    all over the map and fixing these userspaces to
    do the right thing, it makes sense to make the
    right thing the default.

    And these are millions and millions of deployed
    systems not using udev+systemd we are talking about,
    they are not fringe hobby projects. It's not that I
    personally dislike udev or anything, I kind of like
    it, but these tailored distros simply don't use it
    and they are huge in numbers. They need help to do
    the right thing. Fixing a udev rule doesn't solve
    even half the world's problems I'm afraid.

    Yours,
    Linus Walleij

    \
     
     \ /
      Last update: 2018-10-04 10:27    [W:4.100 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site