Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Oct 2009 16:25:34 +0200
From:      Ivan Voras <ivoras@freebsd.org>
To:        freebsd-stable@freebsd.org
Subject:   Re: Extreme console latency during disk IO (8.0-RC1,   previous  releases also affected according to others)
Message-ID:  <hb22kn$m3b$1@ger.gmane.org>
In-Reply-To: <B5BA3ACC-BC06-4042-8434-0D9395A0F478@freebsd.org>
References:  <E316139E-FFCF-432F-8DCE-62B120C38E55@exscape.org>	<CC16B639-7A75-4016-A8A8-5C59E9CD5E95@exscape.org>	<hb1qs0$qjd$1@ger.gmane.org>	<alpine.BSF.2.00.0910131406340.26071@fledge.watson.org>	<9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <B5BA3ACC-BC06-4042-8434-0D9395A0F478@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Robert N. M. Watson wrote:
> 
> On 13 Oct 2009, at 14:33, Ivan Voras wrote:
> 
>>> If (1) is highly variable during I/O, it's almost certainly a 
>>> property of
>>> the VM technology you're using, and there's nought to be done about 
>>> it in
>>> the guest OS.
>>
>> Here's an example of a ping session with 0.1s resolution during a few
>> seconds-stall in ssh:
>>
>> 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms
>> 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms
>> 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms
>>
>> 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms
>> 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms
>> 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms
>>
>> note huge packet loss. It looks like it's VM fault or something like it.
> 
> It sounds like the VM is failing to execute the guest during certain 
> types of I/O. A bit of scheduler tracing in the host OS probably 
> wouldn't go amiss to confirm that the VM really is suspending the guest 
> at about the same time ICMP latency goes up. However, given the above I 
> think I you can reasonable assume that the 4ms jump you're seeing there 
> is due to global host OS/VM scheduling, and not FreeBSD scheduling.

Btw. it's not a "4 ms jump" - there are 726 lost packets in between.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hb22kn$m3b$1>