Re: [Xen-devel] [PATCH v3 14/14] AMD/IOMMU: process softirqs while dumping IRTs

[Jan Beulich <JBeulich@xxxxxxxx>]

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 <jbeulich@xxxxxxxx>
>> ---
>> 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.cooper3@xxxxxxxxxx>

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel