On Tue, 2024-04-09 at 12:12 -0400, Benjamin Marzinski wrote: > On Tue, Apr 09, 2024 at 04:38:57PM +0200, Martin Wilck wrote: > > On Fri, 2024-03-29 at 14:28 -0400, Benjamin Marzinski wrote: > > > With this change, if the SCHED_RT_PRIO compiler flag is not set, > > > multipathd will call getrlimit(RLIMIT_RTPRIO, ...) and look at > > > the > > > hard > > > limit. It it's 0, multipath will do nothing. Otherwise it will > > > change > > > its scheduling policy to SCHED_RR and its priority to the hard > > > limit. > > > > > > This allows users to change the priority of that multipathd runs > > > with > > > by > > > adding > > > > > > LimitRTPRIO=<prio> > > > > > > to the [Service] section of the multipathd.service unit file. > > > Setting > > > LimitRTPRIO=0 will make multipathd run as a normal process, while > > > setting LimitRTPRIO=infinity will make it use the maximum > > > SCHED_RR > > > prio, > > > which is 99. > > > > > > Signed-off-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx> > > > > This looks good to me, but do we really need both the RLIMIT_RTPRIO > > and > > the SCHED_RT_PRIO mechanism? > > Not if https://github.com/dracutdevs/dracut/pull/2563 ever gets > merged, > we don't. Unfortunately that PR has caused some regressions in the dracut CI which I haven't had time to analyze / fix yet. > Until then it seemed easier to keep a knob to let us control > this ourselves, rather than try to sync with a change in dracut. > > Obviously, I'm still not convinced that it really matters whether or > not > multipathd is running with SCHED_RR, so we probably could just say > that > until dracut gets updated, we just don't run in SCHED_RR in the > initramfs. I'm fine with pulling the compiler flag if you want. I would prefer to have just one way to configure this, unless we have really strong reasons to support both. Thanks, Martin
