Heiko Carstens wrote: > Hmm.. probably a stupid question: but what could happen that a real cpu > (not virtual) becomes unresponsive so that it won't schedule a MAX_RT_PRIO-1 > prioritized task for 5 seconds? The original problem (once I heard and easily reproduced) was there was an another MAX_RT_PRIO-1 task and the task was spinning in itself by a bug. (Now this would not be a problem since RLIMIT_RTTIME will work for it, but I cannot deny that there are some situations which cannot set the limit.) However there would be more possible problem in the world, ex. assume that a routine work with interrupt (and also preemption) disabled have an issue of scalability so it takes long time on huge machine then stop_machine will stop whole system such long time. You can assume a driver's bug. Now the stop_machine is good tool to escalate a partial problem to global suddenly. >> So I think monotonic wallclock time actually makes the most sense here. > > This is asking for trouble... a config option to disable this would be > nice. But as I don't know which problem this patch originally addresses > it might be that this is needed anyway. So lets see why we need it first. I'm not good at VM etc., but I think user doesn't care who holds a cpu, whether other guest or actual buggy software or space alien or so. The important thing here is return control to user if timeout. Thanks, H.Seto _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
