Op vr 25 jun. 2021 om 10:52 schreef Michal Koutný <mkoutny@xxxxxxxx>: > > On Fri, Jun 25, 2021 at 09:32:59AM +0200, Ronny Meeus <ronny.meeus@xxxxxxxxx> wrote: > > The application does not have strict RT requirements. > > Can you even use the normal non-RT scheduling policy? ... No since we want certain functions (like packet processing) to have a higher priority than for example management activities. > > > We were working with fixed croups initially but this has the big > > disadvantage that the unused budget configured in one group cannot be > > used by another group and as such the processing power is basically > > lost. > > ...then your problem may be solvable with mere weights to adjust priorities > of competitors. (Or if you need to stick with RT policies you can assign > different priorities on task basis, I wouldn't use RT groups for that.) > > > About the stack: it is difficult to know from the SW when the issue > > happens so dumping the stack is not easy I think but it is a good > > idea. > > I will certainly think about it. > > You may sample it periodically or start prior a migration to get more > insights what's causing the delay. > I observed that when I create the cgroups dynamically (at the moment I need them) and immediately assign the threads to it, the symptom seems to be gone. I'm going to observe the system some more to confirm that the problem is really solved in this way. Thanks Michal for the time you spent on this. > Regards, > Michal >
