Re: runsvdir polling
After some more investigation the problem has gone away. I suspect operator error. Specifically the runsvdir CPU usage was likely caused by a misconfigured service that was generating frequent readproctitle messages. Oops. Current CPU time is about 58s over 28 days uptime which seems fine. On Tue, Feb 21, 2017 at 11:15:05AM +0100, Martin "eto" Misuth wrote: > So instead of patching runit, have you considered approaching problem other > way around: modifying your void boot sequence to boot into s6? With my discovery that the CPU problem was my error my motivation to patch or switch is decreased. The one remaining small issue is nesting runsvdir but I'm not going to worry about that for now. > I use void as well, but I am quite unorganized person, so I haven't got very > far in using s6-svscan on void as PID1 yet. For now, I use runit to supervise > s6 > supervision trees, on personal box, at least. > > It seems to me that all that would be needed is wrapping runit's stage1&2 > scripts by execline wrappers, to bring machine up and down and to reuse distro > provided scripts at the same time. s6 service tree should be probably separate > from runit one, most runit services should be "copyable" over into s6 though. > But considering you are competent admin, one would expect you are modifying > most runit run scripts anyway. > > Of course there might be some hidden gotchas. > > Anyway, I guess, that sharing such work, might end up (hopefully) beneficial > to > more people in void community, interested in using s6 instead of runit. At > least, I would be interested in being able to use s6-svscan as PID1 on void. > > What are you thoughts on this? > > eto It doesn't sound too difficult but staying close to upstream makes it less work to track their changes. I also like that enough people use Void that the stock bits are unlikely to be broken when I update. My next project is to try out their mkimage tool and get a RPi + my code build process going.
Re: runsvdir polling
On Sat, 14 Jan 2017 18:54:05 -0800 39066...@gmail.com wrote: > The s6-svscan behavior fits what I want to do, in this case runit is the > distro-provided init and so I think it makes sense to patch runsvdir to avoid > needing to change other parts of the system. It's slightly unfortunate that > runsvdir isn't designed to be nested so I might do that too while I'm in > there. I wouldn't expect runit upstream to be all that excited about either > change though. > You mentioned your distro is Void (void). When I asked on void IRC channel, some time back, void members active there seemed generally happy with runit and there was not much interest in s6. But, switching inits on void, is easy, you just change kernel parameter. Given miniscule size of both runit and s6, it's not a stretch to have both installed. So instead of patching runit, have you considered approaching problem other way around: modifying your void boot sequence to boot into s6? I believe there is much more "value" to gain that way, than fixing runit's servicedir runner. I use void as well, but I am quite unorganized person, so I haven't got very far in using s6-svscan on void as PID1 yet. For now, I use runit to supervise s6 supervision trees, on personal box, at least. It seems to me that all that would be needed is wrapping runit's stage1&2 scripts by execline wrappers, to bring machine up and down and to reuse distro provided scripts at the same time. s6 service tree should be probably separate from runit one, most runit services should be "copyable" over into s6 though. But considering you are competent admin, one would expect you are modifying most runit run scripts anyway. Of course there might be some hidden gotchas. Anyway, I guess, that sharing such work, might end up (hopefully) beneficial to more people in void community, interested in using s6 instead of runit. At least, I would be interested in being able to use s6-svscan as PID1 on void. What are you thoughts on this? eto
Re: runsvdir polling
On Sun, 15 Jan 2017 01:40:13 -0800 39066...@gmail.com wrote: > On Sat, Jan 14, 2017 at 04:10:07PM -0500, Steve Litt wrote: > > On Fri, 13 Jan 2017 21:12:27 -0800 > > 39066...@gmail.com wrote: > > > > > I'm using runit as my primary init on Linux to good effect but > > > have noticed that it accumulates CPU time even while the system > > > is idle. I > > > > How much time in how much uptime? Which process are you looking at > > with this accumulated time? Here's what I get: > > runsvdir has used 1m 55s over a bit under 5 days. The runsv instances > are way less (but then they have no reason to wake). Load average is > 0.00. > > > On my computer, none of this in any practical way affects my > > computing. I would guess on a more heavily used computer, any > > deleterious effects of runit time consumption could be solved by > > running runsvdir and all the runsv's with a positive nice value. > > > > In my opinion, by far the greatest benefit of runit is its > > simplicity, and there's no way I'd trade that for a theoretical > > efficiency benefit. > > That sounds sensible on a desktop. In my case the motivation is to > trim a source of power draw for an image that's going to run on a > battery-powered device that will be awake but idle a lot of the time. > Why Linux? Pretty much familiarity & tooling, if power is ok then I > get to have my cake and eat it too. Why not try s6? IIRC, s6 doesn't poll, is a little more complex than runit, but like runit, it's a daemontools descendent. I've used it and like it. One thing to consider: What is the relationship between the 1m:55s and power consumed? Is power consumption proportional to CPU time, or does it depend on the kind of activity being done? Are disk accesses more, or less power hungry than loops with calculations or other CPU intensive stuff? How would you even find out the answers to these questons? Another question: What sized battery, is it rechargable, and how long do you expect it to last between replacements or recharges? What I'm getting at is this: If power draw is proportional to time, then in 50 days runsvdir would have consumed just under 20 minutes, which is almost nothing if you're using a good sized battery. Are you going to use a superserver? This sounds like a good case for a superserver. You could use xinetd, or the djb-type superserver (can't remember its name). This sounds interesting. SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: runsvdir polling
How much time in how much uptime? Which process are you looking at with this accumulated time? That's not an argument. Even if runit's (or sysvinit's, or...) polling is completely unnoticeable - and on a desktop, to be fair, it definitely is - it doesn't mean that polling is good. Polling is evil for several reasons, the two most important of them being the following. 1. From a software engineering POV: software that depends on underlying polling has to wait for the polling period to be sure its changes have been taken into account. When you have a system A that polls, a system B that depends on A and also polls in another place, etc., the polling periods compound each other, and this can introduce significant delays. I have met a real-life example of this at Google, of all places: sending a high-level command to a batch of servers takes several seconds, sometimes several minutes - not because there's lot of CPU involved, or high network delays, but because Google's software stack is big, and most of its layers perform polling at some point (processing a message queue every second, or every few seconds, instead of getting notified when a new message arrives), and it adds up. Most of Google's high-level commands (start a service on a cluster of servers, change routing tables to direct traffic somewhere else, etc.) spend a whole lot of time doing nothing. Big scripts using high-level commands, such as automated software rollouts, sometimes take hours to complete, whereas the real work involved could be accomplished in 10-15 minutes tops; and software designed around polling is the main culprit. 2. At the complete opposite end of the scale, from an energy consumption POV: you obviously will not notice that on a desktop, but on embedded devices that are supposed to use energy sparingly (think set top boxes in "sleep" mode, battery-powered/handheld devices, etc.), every spurious wake-up counts. Even if, as runit does, you only wake up once every 14 seconds, it means you pull the CPU out of sleep mode - it cannot sleep for extended periods of time. I have also met a real-life example of this, when I was working at Sagemcom (a French manufacturer of embedded devices), making the base system for an energy gateway (the thing that's supposed to collect and report consumers' energy consumption; obviously, for such a task, it should NOT use too much energy itself, else consumers will be angry and have the right to be). I had spent a lot of time and energy trying to convince the project leader that we should not use D-Bus, to no avail; his argument was that D-Bus made communication easy with the Java part (the proprietary application software was in Java). It was making *my* life hell, but whatever, I could take it, I'm not a Java dev snowflake. So I made a cool base system with no polling at all, with low-level software reporting data to D-Bus, and shipped it to the Java people. Later on, testing showed that the energy consumption was through the roof, and the board was brought back to us for analysis; what we discovered was that the chosen JVM implemented its D-Bus client by actually polling its message queue every tenth of a second. Yes, the thing was waking up 10 times per second. Really. And, obviously, none of the tweaks we made were of any help: increasing the polling period did not cut down energy consumption quite enough, but it did cause significant delays in the handling of D-Bus data. I don't know what became of the project, because I left the team at that time (my part worked, so there was no reason for me to stay there, so they put me on another project), but so far I haven't heard of a Sagemcom energy gateway being deployed in people's homes. When you're an init system, i.e. the lowest possible level for user-space software, and you *already* introduce polling, well, it doesn't bode well for the rest of your software stack. Your energy-saving device is already screwed, and automation that relies on runsvdir picking up a new service is already eating an average 7 second delay. As a desktop user, you obviously don't care; as a software architect, this makes me shake my head. Even systemd does better on that point. -- Laurent
Re: runsvdir polling
On Sat, Jan 14, 2017 at 04:10:07PM -0500, Steve Litt wrote: > On Fri, 13 Jan 2017 21:12:27 -0800 > 39066...@gmail.com wrote: > > > I'm using runit as my primary init on Linux to good effect but have > > noticed that it accumulates CPU time even while the system is idle. I > > How much time in how much uptime? Which process are you looking at with > this accumulated time? Here's what I get: runsvdir has used 1m 55s over a bit under 5 days. The runsv instances are way less (but then they have no reason to wake). Load average is 0.00. > On my computer, none of this in any practical way affects my computing. > I would guess on a more heavily used computer, any deleterious effects > of runit time consumption could be solved by running runsvdir and all > the runsv's with a positive nice value. > > In my opinion, by far the greatest benefit of runit is its simplicity, > and there's no way I'd trade that for a theoretical efficiency benefit. That sounds sensible on a desktop. In my case the motivation is to trim a source of power draw for an image that's going to run on a battery-powered device that will be awake but idle a lot of the time. Why Linux? Pretty much familiarity & tooling, if power is ok then I get to have my cake and eat it too.
runsvdir polling
I'm using runit as my primary init on Linux to good effect but have noticed that it accumulates CPU time even while the system is idle. I suspect that this is a consequence of runsvdir polling the service directory for changes and that using inotify would reduce this. This would introduce some complexity and variance between platforms but bring the benefit of removing a source of CPU wake-ups. Has using inotify been considered and rejected for another reason?
