Re: [Xen-devel] VIRQ_CON_RING

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 12.11.09 15:51 >>>
>On 12/11/2009 14:19, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> While I realize that for compatibility reasons (even in the case of there
>> not being a current user) it may not be possible to drop this vIRQ
>> altogether, I wonder whether it would be possible to avoid scheduling
>> the tasklet when the vIRQ has no handler and/or is already pending.
>
>So this is due to you adding a really noisy printk in the middle of a
>hypercall? I don't think you should expect goodness to result from that.

No, it wasn't really meant to be that noisy (e.g., it was printing only as
long as a guest didn't have a page fault handler registered, and now
that I relocated the printing [without changing their amount] I know
that after an initial burst this printed just about a dozen lines).

>Seems to me the issue is as much the extreme load you put on printk as it is
>printk's overhead.

I don't think so: Since __putstr() calls tasklet_schedule() directly and
(basically) unconditionally, it is clear that after every printk()
hypercall_preempt_check() will return true, and hence placing one
anywhere before such a check will make sure that preemption is going
to happen. Since the code path will be the same after the continuation
hypercall got invoked, it is impossible to make any progress if the
preemption check is placed at the beginning of a handler/loop (and
even if, like in alloc_l[34]_table(), it is placed after having done at
least one iteration, progress is possibly going to be unnoticeable).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel