Re: [Xen-devel] [xen-unstable test] 112855: regressions - trouble: blocked/broken/fail/pass

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.08.17 at 17:36, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 08/28/2017 10:52 AM, Jan Beulich wrote:
>>>>> On 28.08.17 at 16:24, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>>>> As for periodically testing process_pending_softirqs() we may still want
>>>>> to do this in alloc_heap_pages(), even without CONFIG_SCRUB_DEBUG.
>>>> For my taste, alloc_heap_pages() is the wrong place for such
>>>> calls.
>>> But the loop is in alloc_heap_pages() --- where else would you be testing?
>> It can only reasonably be the callers of alloc_heap_pages() imo.
>> A single call to it should never trigger the watchdog, 
> 
> check_one_page() is rather slow so for a large order allocation even
> with clean heap the 'for' loop may take quite some time. Whether it
> could trip the watchdog -- I don't know.

If that was a problem, we'd have to think about shortening the
loop. I stand by my assertion that nowhere down from
alloc_heap_pages() should be any invocation of
process_pending_softirqs() - it is simply too risky, as we don't
know what state we're in. One thing I could imagine to do is not
check the entire page, but (randomly?) pick a couple of locations
to check. But first of all we really need to be clear about whether
it's really a single alloc_heap_pages() invocation that trips the
watchdog, or whether something can be done about it in the
caller(s).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel