From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 14:26:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37ECA106566B for ; Tue, 13 Oct 2009 14:26:06 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B75DF8FC13 for ; Tue, 13 Oct 2009 14:26:05 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MxiK0-000412-1L for freebsd-stable@freebsd.org; Tue, 13 Oct 2009 16:25:52 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Oct 2009 16:25:52 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Oct 2009 16:25:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 13 Oct 2009 16:25:34 +0200 Lines: 31 Message-ID: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: Sender: news Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 14:26:06 -0000 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.