Announcement

Collapse
No announcement yet.

Arcan 0.6 Display Server Adds Network Transparency, XWayland Client Isolation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by oiaohm View Post

    Systemd integrationin kde and gnome is not without very valid reason. There is a fault with the Linux kernel.

    Linux kernel is wacky. When you get to the Linux kernel scheduler it has no concept of what a process is. All the Linux kernel schedulers know is really threads and cgroups/namespaces are. So we have two process under Linux one starts 50 threads and the another starts one the one that starts 50 threads by default gets 50x more CPU/IO... than the one that started 1 thread.

    So no systemd intergration fine but cgroup support has to come from somewhere or resources are going to keep on being allocated fairly between threads. On the desktop for responsiveness there are lots of times you want unfair resource allocation as the the active window application getting more resources than general as well as the core bits like the display server not being staved for CPU/IO.

    There are a set of stall behaviours on the Linux desktop that are purely being too fair.
    I am not sure I would say wacky After all by default the kernel should strive for fairness and efficiency. Because the kernel cannot yet read minds, we must give it hints about how we want various tasks treated. In the old days, this was mostly something like 'nice' to raise or lower priority, or choosing a different scheduler regime (such as realtime).

    But as you imply, the pieces exist to do what you desire, it just falls to the desktop or distribution to implement them. Systemd (and openrc) already put all the services they start into their own cgroup, allowing control over how they share memory, cpu and other resources. Years ago they included a little hack in the kernel that would automatically group tasks based upon session, so that for example your desktop could be protected from aggressive CPU burners in other sessions. (I am not sure if this is enabled by default in distro kernels...)

    This just needs further refinement to wrangle different groups of tasks in the same session if desired. For example, I myself have a terminal window that I use for intensive compile jobs that are all contained in a special cgroup, so that it does not degrade the rest of the desktop. (I also launch chrome and firefox into their own cgroups-- which neatly contain all their spawned threads/processes.) I believe android already does this for all 'apps'. The other thing this type of grouping (or use of different namespaces) allows is firewalling/QoS/shaping per group of tasks...

    Comment


    • #12
      Originally posted by set135 View Post
      I am not sure I would say wacky After all by default the kernel should strive for fairness and efficiency. Because the kernel cannot yet read minds, we must give it hints about how we want various tasks treated. In the old days, this was mostly something like 'nice' to raise or lower priority, or choosing a different scheduler regime (such as realtime).
      Linux is wacky for the first 15 years of Linux nice value was just a stored value totally ignored by the scheduler. Nice values only worked on Linux after cgroups had been in for a few years even then not as expected. So placebo effect was how nice worked in Linux before cgroups. Yes you can still choose to build Linux with a scheduler that makes nice value nothing more than placebo.

      https://superuser.com/questions/8055...-shell-is-used
      This is the way nice value when they work on Linux when they work. Nice values only processed against processes in the same cgroup/autogroup. Nice on Linux has never been a system wide thing.

      Turns out giving the Linux kernel hints on what you want it to-do is insanely limited. cgroups is how you give it hints.

      Old days we did X normally means under Unix or BSD we did X but there is a lot of cases where people keep on doing X on Linux and its not working but not spitting out a error but they say it works because they are placebo effect themselves. Nice is one of those ones. Nice on Linux does not work like it does on Minix, BSD or Unix systems.

      There are quite a few areas of Linux only strangeness.

      Originally posted by set135 View Post
      But as you imply, the pieces exist to do what you desire, it just falls to the desktop or distribution to implement them. Systemd (and openrc) already put all the services they start into their own cgroup, allowing control over how they share memory, cpu and other resources. Years ago they included a little hack in the kernel that would automatically group tasks based upon session, so that for example your desktop could be protected from aggressive CPU burners in other sessions. (I am not sure if this is enabled by default in distro kernels...)
      This would be autogroup. This does not turn out to good why you have logind started doing cgroups by placing them in the tree right you can do user vs user biasing instead of who has the most logins winning. If you check your pid 1 on most distributions you will still find autogroup entry there. Anything with a cgroup is removed automatically from the autogroup stuff.

      Originally posted by set135 View Post
      This just needs further refinement to wrangle different groups of tasks in the same session if desired. For example, I myself have a terminal window that I use for intensive compile jobs that are all contained in a special cgroup, so that it does not degrade the rest of the desktop. (I also launch chrome and firefox into their own cgroups-- which neatly contain all their spawned threads/processes.) I believe android already does this for all 'apps'. The other thing this type of grouping (or use of different namespaces) allows is firewalling/QoS/shaping per group of tasks...
      Exactly.
      http://blog.davidedmundson.co.uk/blo...n-the-desktop/

      KDE and Gnome are working to the path that using systemd user on Linux all this cgroup stuff is setup for all users without them having to do as much or know as much.

      cgroups are the only way you can really be giving the scheduler useful hints with Linux.

      Comment

      Working...
      X