On Wed, 2014-05-14 at 15:11 -0400, Paul Gortmaker wrote: > Given that, perhaps a separate change to sched_rt_runtime_exceeded() > that works out the CPU from the rt_rq, and returns zero if it is a > nohz_full cpu? Does that make sense? Then the nohz_full people won't > get the throttling message even if they go 100%. I don't get it. What reason would there be to run a hog on a dedicated core as realtime policy/priority? Given no competition, there's nothing to prioritize, you could just as well run a critical task as SCHED_IDLE. I would also expect that anyone wanting bare metal will have all of their critical cores isolated from the scheduler, watchdogs turned off as well as that noisy throttle, the whole point being to make as much silent as possible. Seems to me tick_nohz_full_cpu(cpu) should be predicated by that cpu being isolated from the #1 noise source, the scheduler and its load balancing. There's just no point to nohz_full without that, or if there is, I sure don't see it. When I see people trying to run a hog as a realtime task, it's because they are trying in vain to keep competition away from precious cores.. and one mlockall with a realtime hog blocking flush_work() gives them a wakeup call. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
