Announcement

Collapse
No announcement yet.

BUS1 Working On "r-linux" - A Rust Capability-Based Linux Runtime

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

  • #51
    Besides, did you even read the answers in the stack exchange question you linked to? What do they say?

    Comment


    • #52
      Originally posted by sinepgib View Post
      What I implied is a fact: parallelism is better for starting many independent services (or with clusters of dependencies) performance wise than sequential startup, and shells add massive overhead, specially if the actual service is quick to start.
      Sysvinit was not sequential by the time of systemd or upstart.
      https://manpages.debian.org/wheezy/s...tpar.8.en.html

      Note the date on this man page of 2003 yes upstart is 2006 and is 2010. Yes it 2003 when sysvinit with shell scripts got parallelism.

      "Starting many independent services (or with clusters of dependencies)" predates systemd. You have basically missed that Parallelism startup with shell existed.

      https://wiki.debian.org/LSBInitScripts
      The Linux standard base extra meta data being added to sysvinit scripts for services is also from 2003. So sysvinit 2003 also have clusters and dependencies. Of course not very clear to users when something was badly wrong.

      So its "Parallelism startup with shell" vs upstart and systemd that comes latter.

      I am starting to see the cause of your mistake.. Turns out shells overhead was not that massive compared what you need so everything can work correctly. Sinepgib systemd using pidfd and cgroups has overhead. Lot more performance overhead than one would otherwise presume.

      Systemd will spend more time with threads waiting for the kernel to deal with locking be this cgroups because there is locking there to record the cgroup information to deal with PID tree breaking issues or be it using PIDFD again there is need form of locking to prevent problems caused by PID recycling. This waiting has a performance cost. Note I said that sysvinit with shell could be faster but its consumer more power this CPU processing more instructions not being stuck waiting. Time at wall sysvinit is fast power usage sysvinit is worse.

      So it depends how you measure performance. If you are measuring performance by power usage systemd is better if you are measuring by startup time sysvinit is better.

      Parallelism with sysvinit is problem because you are depending on optional comments in the shell to be correct to have the configuration scripts process everything and configure everything so it starts up correctly. Advantage of systemd service files you are not getting anywhere if you don't fill in the basic information for parallelism this is advantage over upstart as well. Lot of people got upset with systemd sysvinit compadiblity layer as well because if you did not have your LSB extra comments it would just skip your service until you added them.

      sinepgib you were making a mistake that the system prior to systemd and upstart was still sequential startup. Sequential startup started not being used in 2003.

      Systemd selling points over sysvinit should read as.
      1) slightly better power effectiveness.
      2) Resistant to miss configuration of the parallelism startup(it still possible but less so).
      3) Proper service management due to not having the PID issues from the usage of cgroups and pidfd.
      Sysvinit selling points over systemd.
      1) Faster start up by insanely small margin if configured correctly.

      Yes if sysvinit was starting up sequential mode it would have been a pure walkover for systemd or upstart in performance. But that was not the historic case that by the time systemd and upstart came along. Distribution sysvinit usage was parallelism a few years before upstart and 7 years before systemd.

      The reality here kind of horrible. If posix shell script had been improved like having pidfd equal required by the posix standard then you init scripts using that this would have improved the service management a lot. Of course to fix all Linux problems you need cgroup support as well but there are a lot of Unix and Unix like systems that don't have the PID tree breakage problem in their kernels.

      sinepgib interesting right when you dig into it having a shell based init/service management system does not have to be poor performing. The reality is when you dig into it the shell cannot be 100 posix conforming because you are needing extensions for items like pidfd. This is where the complete problem of demanding that the shell be posix conforming falls in on it face.

      sinepgib you are basically using rose colour glasses to make the history look how you expect. You need to take those glasses of and notice that parallelism was earlier event. Shell based service management is part of the Linux world parallelism in start-up history as a operational solution. Please note I said operational solution not as functionally good solution.

      Comment


      • #53
        Again with assuming I am drawing a comparison with systemd. Answer these two questions:
        1. Did sysvinit get faster after getting parallelism in?
        2. Did sysvinit get faster after replacing Bash with Dash?

        Regarding its implementation, it worked so badly due to dependency management and parallelism itself being afterthoughts that nobody would enable it by default and most would discourage its use.

        But rest assured, I am not under any confusion here, you are answering claims I did never make about projects I did never mention. I am aware of all those things, the reliability problems of sysvinit that are the actual reason of its replacement. I could also add that cross platform support was always rather moot, as opposed to the option of easily using alternatives on Linux, since only a few chimeras used sysvinit without a Linux kernel (proper BSDs use their own init, only Debian/kFreeBSD used sysvinit and I have yet to meet somebody who doesn't notice the contradiction of using that).

        Comment


        • #54
          Originally posted by sinepgib View Post
          Again with assuming I am drawing a comparison with systemd. Answer these two questions:
          1. Did sysvinit get faster after getting parallelism in?
          2003 is when sysvinit gets parallelism management interfaces. First example of sysvinit starting services up in parallel is it first version. Posix shell supports threading. So the trap here is sysvinit always had parallellism there was a major usability issue. Early sysvinit far user-unfriendly at parallelism before 2003 that people incorrect presume it was a new feature because distributions were not using the feature. So did parallelism make sysvinit faster no because it could not because you are talking about a day 1 feature in the open source thing called sysvinit and the platform sysv init it design was based on. Yes the platform sysv init parallelism configuration nightmare as well to the point operators of that platform did not use parallelism unless they absolutely had it.

          Originally posted by sinepgib View Post
          2. Did sysvinit get faster after replacing Bash with Dash?
          This is what happens when you only look at a point in history on one distribution not all of it. Bash progressively got slower over the years as it added features. sysvinit is dash is in fact slower than sysvinit with a early less feature full version of Bash. Also not every distribution used sysvinit with bash or dash.

          So this is really not as black and white as it first appears. Could you cripple sysvinit performance by using over feature filled version of bash yes you could. Do note that /bin/sh when used with bash disables a huge stack of bash features from being used. So problem here bash is loading a stack of code into memory and worse setting up for use that never going to be used in the init process.

          Remember sysvinit your shell script is meant to be limited to only posix standard define features. This limitation comes from the where the Linux sysvinit design was copied from being the sysv platform. Being on the sysv platform limiting the init scripts to posix standard features was not a problem.

          Originally posted by sinepgib View Post
          Regarding its implementation, it worked so badly due to dependency management and parallelism itself being afterthoughts that nobody would enable it by default and most would discourage its use.
          This is another area where people go down non factual rabbit hole. Few things you need to come aware of the sysv platform the origin point of the sysvinit design lacks a few problems. PID numbers on sysv platform can only be used once per boot when system runs out of new PID numbers the system crashes so this historic system does not suffer from PID recycling or PID tree breaking.. Using PID value in file for detecting if a dependency was started or not was valid on the sysv platform.

          The reality here is sysvinit on Linux design is really a round peg in a square hole problem. Yes how to do dependency management and parallelism is in the sysvinit design from day one. Problem here is the design presumes that you PID don't recycle and your PID tree cannot break it interconnects.

          There is a fundamental difference between the origin of the sysvinit design and where it ends up being used. That difference effectively renders many parts of the sysv init design not functionally usable.

          Fundamental difference between the origin of a init solution design and Linux resulting in implementation of that init system design on Linux not being correctly functional is not unique to sysvinit.

          Also be aware by end 2003 debian was enabling parallelism in sysvinit by default along with many other distributions. Yes 2003 is when we see the LSB work around to .pid files not being dependable due to contained PID value not being dependable.

          Originally posted by sinepgib View Post
          But rest assured, I am not under any confusion here, you are answering claims I did never make about projects I did never mention. I am aware of all those things, the reliability problems of sysvinit that are the actual reason of its replacement. I could also add that cross platform support was always rather moot, as opposed to the option of easily using alternatives on Linux, since only a few chimeras used sysvinit without a Linux kernel (proper BSDs use their own init, only Debian/kFreeBSD used sysvinit and I have yet to meet somebody who doesn't notice the contradiction of using that).
          Yes like this cross platform is moot claim you see it a lot. This complete ignores that reason why sysvinit does not work is itself is a cross platform design that was not designed to fit the Linux kernel. Turns out sysvinit implement on kernel that matchs what it designed for is a lot more feature complete than people assume.

          Sysvinit has a reliability problem on Linux and OS with PID recycling because the design was not designed for that behavour.

          FreeBSD own init uses their equal to PIDFD and FreeBSD has PID recycling..... Debian/kFreeBSD using sysvinit should be straight up alarm bells here is a design that is sysvinit that is not designed for a kernel that does PID recycling and now you are using sysvinit with a kernel with PID recycling. So a little more than a contradiction. Yes its a little more than a contradiction to be using sysvinit with the Linux kernel.

          The problem with sysvinit is that it was a decade old design that a person read out of a old book and brought to Linux and in the decade before sysvinit appeared on Linux OS operation changed a lot. Yes the source of the sysvinit design is 1983 UNIX System V yes that based off older UNIX System III 1982 so its at least a decade old design by the time Linux starts implementing the design.

          Interesting point freebsd own init system(and most other BSD init systems) is a direct descendant from Unix System V init system. Please note descendant not 1 to 1 copy but connected by source fragments. The BSD developers were willing to change and improve init system to keep up with current kernels this includes ignoring and extend posix standard where it made sense.

          Yes you could say having the open source sysvinit on freebsd is very much like allowing the bind and bat cousin of your great great great great grandfather who only knows how to driver a horse and wagon correctly attempting to drive your modern day car. Yes those 4 greats before grandfather are based on the Unix time line from sysv init origin point to current day freebsd init system with all the major alterations to make it compatible with modern day kernels.

          Us using linux with sysvinit was using a very badly out of date and incompatible solution. But that design solution put on system that design is for is very competent. Yes that great great great great grandfather given a old school horse and cart and a person who is use to modern only with only horse and cart is the one going to be in trouble right. Remember these examples the people are basically immortal because software is.

          This is what created the sysvinit problem the person saw sysv init on sysv compatible OS and the thing was brilliant with every feature you could want in a init system. Then it lands on Linux and 90% of those features no longer work all due to Linux kernel being a PID recycling OS then another 7% don't work due to PID tree breaking. Yes so left with only 3% of the starting features. There is over 300 features that the old sysv init had in usage.

          sinepgib the reality you have most likely never seen how good sysvinit should have been. This results in you thinking it did not have X feature. When in reality most of the time you will find sysvinit has X feature just that X feature is not usable because it either depends on PID not recycling or PID tree not breaking.

          Also we need to learn this lesson because we don't want to be 2 decades into the future and find that systemd... have in fact stagnated and drifted into being incompatible with modern day kernels.

          Comment

          Working...
          X