On 19.07.2019 19:55, Andrew Cooper wrote: > On 16/07/2019 17:41, Jan Beulich wrote: >> When there are sufficiently many devices listed in the ACPI tables (no >> matter if they actually exist), output may take way longer than the >> watchdog would like. >> >> Signed-off-by: Jan Beulich <jbeul...@suse.com> >> --- >> v3: New. >> --- >> TBD: Seeing the volume of output I wonder whether we should further >> suppress logging headers of devices which have no active entry >> (i.e. emit the header only upon finding the first IRTE worth >> logging). And while minor for the total volume of output I'm >> also unconvinced logging both a "per device" header line and a >> "shared" one makes sense, when only one of the two can actually >> be followed by actual contents. > > I don't have a system I can access at the moment, so can't judge how bad > it is right now. However, I would advocate the removal of irrelevant > information.
I'll try to get to putting together another patch to this effect. > Either way, this is debugging so Acked-by: Andrew Cooper > <andrew.coop...@citrix.com> Thanks, also for all the other review of this series! > As an observation, I wonder whether continually sprinkling > process_pending_softirqs() is the best thing to do for keyhandlers. > We've got a number of other which incur the wrath of the watchdog (grant > table in particular), which in practice means they are typically broken > when they are actually used for debugging production. > > As these are for debugging only, might it be a better idea to stop the > watchdog while keyhandlers are running? The only useful thing we > actually manage here is to stop the watchdog killing us. Hmm, I would agree going this route if the watchdog could be disabled on a per-CPU basis, but right now watchdog_disable() is a system wide action. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
