On 02/03/23 13:56, Michal Hocko wrote: > On Thu 02-03-23 12:30:33, Valentin Schneider wrote: >> On 02/03/23 12:24, Michal Hocko wrote: >> > On Thu 02-03-23 10:18:31, Valentin Schneider wrote: >> >> On 02/03/23 08:45, Michal Hocko wrote: >> >> > On Wed 01-03-23 18:23:19, Valentin Schneider wrote: >> > [...] >> >> >> I want cgroupv1 to die as much as the next person, but in that specific >> >> >> situation I kinda need cgroupv1 to behave somewhat sanely on RT with >> >> >> threshold events :/ >> >> > >> >> > Could you expand on the usecase? >> >> > >> >> >> >> In this case it's just some middleware leveraging memcontrol cgroups and >> >> setting up callbacks for in-cgroup OOM events. This is a supported feature >> >> in cgroupv2, so this isn't a problem of cgroupv1 vs cgroupv2 feature >> >> parity, but rather one of being in a transitional phase where the >> >> middleware itself hasn't fully migrated to using cgroupv2. >> > >> > How is this related to the RT kernel config? memcg OOM vs any RT >> > assumptions do not really get along well AFAICT. >> > >> >> Yep. AIUI the tasks actually relying on RT guarantees DTRT (at least >> regarding memory allocations, or lack thereof), but other non-RT-reliant >> tasks on other CPUs come and go, hence the memcg involvement. > > So are you suggesting that the RT kernel is used for mixed bag of > workloads with RT and non RT assumptions? Is this really a reasonable > and reliable setup? > To some extent :-) > What I am trying to evaluate here is whether it makes sense to support > and maintain a non-trivial code for something that might be working > sub-optimally or even not working properly in some corner cases. The > price for the maintenance is certainly not free. That's also what I'm trying to make sense of. Either way this will be frankenkernel territory, the cgroupv1 ship has already sailed for upstream IMO.
