Re: [Xen-devel] Re: [Xen-users] About profiling xen

[Marco Tizzoni <marco.tizzoni@xxxxxxxxx>]

On Thu, Oct 1, 2009 at 10:54 PM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 10/01/09 00:35, Marco Tizzoni wrote:
>> On Thu, Oct 1, 2009 at 1:23 AM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>>
>>> Your clocksource is "xen", which is the best possible for a PV xen guest.
>>>
>>> However, a clocksource is for measuring elapsed time, not triggering
>>> timers.
>>>
>> Why? How would you solve the problem of raising events at a fixed rate?
>>
>
> I'm not sure I follow you.  In the kernel, the clock*source* subsystem
> is for measuring time: its used to implement gettimeofday, as well as
> internal time accounting.  It isn't directly related to time events.

Ok.

> The clock*event* mechanism is all about setting up timers to raise events.
>
> When running paravirtualized, we use Xen-specific versions of both.

Ok.  My problem is granularity. In xen I can't raise events more
frequently than 1000/s (with timer set to 1000hz).
Net test softwares such as netperf or hping use setitimer to send
packet at a fixed rate. On a non-xen box they works fine even  with
100k packets/sec (i.e. 100k alarms/sec). This can be problematic for
streaming software and more in general for soft real-time
applications.

>>> Unfortunately there doesn't seem to be a /sys file to show the
>>> current clockevent source in use, but if you have "xen" clocksource it's
>>> almost certainly the xen clockevent.
>>>
>>> However, this is only relevent if you have CONFIG_NO_HZ and
>>> CONFIG_HIGHRES_TIMERS enabled.
>>>
>> I've tried both set/unset but nothing change.
>>
>
> Hm.  Its best to leave both enabled either way.
>
> Try the attached program to get some info about how well timers are
> working.  Compile with:

Thanks for your test, I tried and timers work as expected.

m-

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