This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] VIRQ_CON_RING

>>> 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).


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>