[systemd-devel] How to schedule a resource consuming service

[Jérémy ROSEN]

I had proposed https://github.com/systemd/systemd/pull/7023 as a way to
deal with a similar problem. This might help you.

The idea is to have a timer trigger 5' after boot and hace the timers you
are interested in be started by that timer. This allows to make sure they
are not triggered in the 5' after boot

that's not exactly what you want (it's after boot, it doesn't deal with
hibernation) but it might give you ideas

HtH



Le lun. 4 févr. 2019 à 13:04, Lennart Poettering <lennart at poettering.net> a
écrit :

> On Sa, 02.02.19 14:50, Fabrice Salvaire (fabrice.salvaire at orange.fr)
> wrote:
>
> > This is painful when we want to use the machine asap, for a quite full
> 500
> > GB disk, it hangs during several minutes.  I encountered an unusable
> machine
> > during more than 10 min due to mlocate and/or gnome indexer saturating IO
> > and package cache update saturating a low ADSL connexion.
> >
> > I noticed IOSchedulingClass=2 could be set to "idle", maybe it would
> > improve.
>
> Setting IOSchedulingClass to 2 is equal to "best-effort", which is
> actually the Linux default.
>
> Setting to "idle" might work, but I am not sure it's really the ideal
> approach either, as it means that this service could be starved out
> entirely until all eternity if something else wants IO
> constantly. Usually it's better and sufficient to just set the Nice=
> level to something really high, as that propagates to both the CPU and
> IO schedulers, and means that everything else will be scheduled
> preferably, but your service will still get a bit of CPU/IO time every
> now and then so that it doesn't starve to death. (that said, playing
> around with "idle" might definitely be worth the excercise)
>
> Quite frankly, if Nice=19 is not sufficient for your usecase, and this
> still affects behaviour of your system too badly, then this indicates
> that the IO scheduler on selected on your system isn't any good or the
> hw really limited?
>
> If nicing some IO heavy job to 19 still affects everything else so
> badly, then ultimately I figure this becomes a question for the kernel
> IO folks. systemd after all can only tell the kernel at what priority
> to schedule something, how things are actually scheduled is done by
> the kernel itself.
>
> > I also read
> > https://www.freedesktop.org/software/systemd/man/systemd.timer.html but
> I
> > don't understand if there is a way to prevent to run the service during
> 1h
> > after boot.
>
> There's currently no concept of defining "negative" timers, i.e. to
> first say "run this so and so often", but then say "but not at these
> times". It might be worth adding that, but this would require a bit of
> work, and I am not sure how the syntax could look like...
>
> > Well a way to run theses services during idle time.
>
> We have no concept for that. The assumption so far that the Linux IO
> scheduler is good enough so that we don't have to second guess it, and
> it knows on its own when it's a good time to schedule a process as
> long as we tell it a useful priority...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190204/f726b122/attachment.html>