From owner-freebsd-current@FreeBSD.ORG Mon Jul 25 08:41:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD7CA106566B for ; Mon, 25 Jul 2011 08:41:25 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id 028F38FC08 for ; Mon, 25 Jul 2011 08:41:24 +0000 (UTC) Received: (qmail invoked by alias); 25 Jul 2011 08:41:23 -0000 Received: from g229210208.adsl.alicedsl.de (EHLO apollo.emma.line.org) [92.229.210.208] by mail.gmx.net (mp018) with SMTP; 25 Jul 2011 10:41:23 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX19Q/lxy7ttQLkSLMRjKDJvinLeRTtdDeg2dV+Sq8I CqWiVO6fYKzJ80 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 90D8F23CE50 for ; Mon, 25 Jul 2011 10:41:22 +0200 (CEST) Message-ID: <4E2D2C32.5010602@gmx.de> Date: Mon, 25 Jul 2011 10:41:22 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Mnenhy/0.8.3 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110724212544.GA57733@freebsd.org> <20110725072102.GA24938@freebsd.org> In-Reply-To: <20110725072102.GA24938@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: chromium port causing massive I/O faults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 08:41:25 -0000 Am 25.07.2011 09:21, schrieb Alexander Best: > On Mon Jul 25 11, Adrian Chadd wrote: >> Is it perhaps doing disk IO using mmap? > > how can i check, whether that's the case or not? Use truss(1) for instance. However, unless there are *practical* problems, a high number of page faults is not an indication for problems. Although it may sound scary, page faults are a feature of the memory management.