[systemd-devel] Power aware units

[Lennart Poettering]

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?

> 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. 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? 

> 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?

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

> > 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?

> > (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?

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

> > 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).

> 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...

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

Lennart

-- 
Lennart Poettering, Red Hat