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 <[email protected]> > > 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. 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. -Ben > > Thanks, > Martin
