[systemd-devel] Power aware units

Tue Nov 5 00:39:33 PST 2013

On Mon, 2013-11-04 at 16:52 +0100, Lennart Poettering wrote:
> On Mon, 04.11.13 16:10, Bastien Nocera (hadess at hadess.net) wrote:
> 
> > > And I figure other ones to add here are:
> > > 
> > > - mandb cache cleanups
> > > - rotation of legacy log files
> > > 
> > > (are there more usecases you can come up with?)
> > > 
> > > All these are exclusively cronjobs, i.e. services triggered only by
> > > time, and nothing else.
> > 
> > Those _were_ all cron jobs. I don't think that any of those should be
> > cron jobs, especially the 4 AM update-db or man-db runs. Anacron is just
> > patching over the fact that most machines aren't running at that time of
> > day.
> 
> Well, but if not cronjob, what should they be?

For me, a cron job is something executed by cron. This should be
executed, once a day, when the screen is locked, on AC battery, and not
under any resource pressure (especially RAM). They're non-essential
functions, and I don't think they should be running if I'm in front of
my computer if I'm using it, even at 4AM.

> > Automatically installing application updates is another use case, or
> > tracker indexing files. Basically, anything that runs in the background
> > without direct user interaction.
> > 
> > >  And all of these strike me as things where we
> > > really should run them on battery too, as not doing them at all will
> > > sooner or later have a negative effect on the stability and safety of
> > > the system.
> > 
> > I don't think that update-db or man-db should be updated when on
> > battery, and even less when on low battery.
> 
> Well, let's say you have a tablet or so which is never attached to AC,
> but where people simply replace the battery when it runs empty with a
> new charged one.

There's still hardware like that? If that were the case, I wouldn't make
it run under low battery then.

>  You certainly wan't these cronjobs to eventually run. I
> mean, if you installed man-db/update-db you probably want them to work
> correctly, no? 

They're installed by default on a lot of distributions (they are, at
least on Fedora), so yes, you want them to work correctly, but not at
the detriment of other tasks or your battery life.

> > It also shouldn't wake up the hard disk, or be run when I have
> > interactive tasks on-going (eg. it should run when the screen lock is
> > on, not in the middle of streaming a film).
> 
> Hmm, well, is the policy here that clear? I mean, if our kernel IO/CPU
> schedulers were any good then scheduling these things while you watch a
> movie should actually have no drawbacks, and even more be a good thing
> since the CPU is awake anyway and it's always good to do things when the
> CPU is awake anyway.
> 
> We should be *very* careful in basically adding a "second-level
> scheduler" here that executes jobs when the CPU load is low, because we
> don't trust the "first-level scheduler" in the scheduler. A scheduler
> that watches another scheduler, and tries to detect when it is idle
> sounds like trouble. Major trouble.
> 
> At this point I am quite sure we don't even make use of all the
> functionality the existing IO/CPU scheduler exposes, and hence there's
> really no reason to add a "second-level" scheduler on top. For example,
> do we actually set those cron jobs to SCHED_IDLE and IOPRIO_CLASS_IDLE?

We already have a way to detect idle, the screensaver being on, and yes,
we should be setting those jobs to have extremely low priority. But they
also shouldn't be running when on low battery.

> (And also possible on the other end, do we set the bits necessariy for
> video playback to something rt'ish?)

No, not right now, because we'd need to make X rt'ish, etc. That's
probably another discussion.

> > > So, would this make sense to you? Is there anything this logic wouldn't
> > > cover?
> > 
> > You want backups to run when on AC and the screen is locked (or even
> > better, when the machine is supposed to be sleeping, with the lid closed
> > for laptops).
> 
> But why exactly do you want this? Because our current IO/CPU scheduler
> setup causes these jobs to interfere too much with your foreground work?
> Or is there more to it?

Because they might interfere with your work. This isn't all about
schedulers, it's also about network usage, and battery usage.

> > > (Oh, and also note that there actually already is ConditionACPower=
> > > which allows you to skip execution of certain services if AC is plugged
> > > in/is not plugged in. See systemd.unit(5) for details).
> > 
> > It doesn't include UPS status, it doesn't know when the hard disk is
> > sleeping, it doesn't know when the screen lock is on.
> 
> Hmm, so correct me if I am wrong: UPS stuff is only last-resort kind of
> stuff: i.e. when we run off UPS we are in the process of shutting down
> anyway, right? I mean, UPSes are not something that is used for
> continous operation, it's just the fallback in the case shit happens?

UPSes are continuously plugged in, you need to know its state to be able
to act upon it. So for every mention of "low battery" above, think of
the UPS discharging as "critical battery". You have 10/15 minutes of
battery left to get your work in order before the machine will be
cleanly shut down. You wouldn't want an indexer of any sort to start and
eat out your battery when you're trying to conserve as much energy as
possible.

> Upower doesn't know when the disk is sleeping either, does it? I am not
> sure even the kernel knows this? 

udisks knows it, at least. I'm not sure whether it's cached by the
kernel.

> > > It certainly would make sense, but my plan was to first add a couple of
> > > things to our timer logic implementation that is substantially better
> > > than classic cron so that we have strong case to make why people should
> > > adopt it. However, never found the time to work on this.
> > 
> > Do you have a list of what's missing?
> 
> The things I had on my list:
> 
> - anacron-like persistency
> - adjust timers to coalesce them once in each second (similar to what
>   sd-event is doing or glib)
> - timer jitter for cluster setups (related to the cluster thing above)
> - timer events that cause the system to resume
> - a "list-timers" command in systemctl (similar to list-sockets)
> - timer evets on DST changes or when the user alters the system time
> - syntax for specifying dates from the end of the month
> - modulate timer frequency based on battery state
> 
> The first five or so I guess are the interesting ones.
> 
> > The benefit in adding usage classes (as Apple did), rather than tweaking
> > each background task manually is that it makes it easier to change the
> > policy for running those, and affect all the uses of that class.
> 
> I have the suspicion that the Apple thing is too opaque for people to
> grok. And I also have the suspicion that in the end the number of
> services that need this is relatively limited (i.e. < 10 on a desktop
> system).

Let's says we don't need the class system used by Apple, we still need
to detect low-battery and UPS discharging. Do we have a way to tell
systemd that this is the current state of the system?

> > I would think that backups, man-db or update-db runs would automatically
> > get the lowest CPU and I/O priorities as possible, you'd mark some of
> > them as easily disposable/interruptible if RAM was scarce.
> 
> Well, we currently have no sane API to get signalled on OOM
> conditions...

Hopefully something like this gets merged:
http://lwn.net/Articles/552789/

And processes that declare themselves as reapable will be on OOM. 

> I am pretty sure though that man-db/update-db things should be lowered
> to IDLE CPU and IO priorities (as described above). 

I think there's still the case of not waking up the hard disk if not
needed, and not launching potentially IO intensive tasks when on low
battery or with the UPS discharging.