>>> Jan Pokorný <[email protected]> schrieb am 01.07.2019 um 14:42 in Nachricht <[email protected]>: > On 01/07/19 13:26 +0200, Ulrich Windl wrote: >>>>> Jan Pokorný <[email protected]> schrieb am 27.06.2019 um 12:02 >>>>> in Nachricht <[email protected]>: >>> On 25/06/19 12:20 ‑0500, Ken Gaillot wrote: >>>> On Tue, 2019‑06‑25 at 11:06 +0000, Somanath Jeeva wrote: >>>> Addressing the root cause, I'd first make sure corosync is running at >>>> real‑time priority (I forget the ps option, hopefully someone else can >>>> chime in). >>> >>> In a standard Linux environment, I find this ultimately convenient: >>> >>> # chrt ‑p $(pidof corosync) >>> pid 6789's current scheduling policy: SCHED_RR >>> pid 6789's current scheduling priority: 99 >> >> To me this is like pushing a car that already has a running engine! If >> corosync does crazy things, this will make things worse (i.e. enhance >> crazyness). > > Note that said invocation is read-only fetch of the process > characteristic. So not sure about your parable, it shall > rather be compared to not paying full attention to driving
Ah, sorry, the heat (here): I was not paying attention, thinking the command was used to set the real-time scheduling parameters, while in fact they had been set already. Apologies! > itself for a bit when checking the speedometer (the check > alone won't presumably run with such an ultimate scheduling > priority, so the interferences shall be fairly minimal, just > as with `ps` or whatever programmatic fetch of such data). > >>> (requires util‑linux, procps‑ng) > > -- > Jan (Poki) _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
