Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423329AbWJaOGL (ORCPT ); Tue, 31 Oct 2006 09:06:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1423336AbWJaOGL (ORCPT ); Tue, 31 Oct 2006 09:06:11 -0500 Received: from rtr.ca ([64.26.128.89]:49168 "EHLO mail.rtr.ca") by vger.kernel.org with ESMTP id S1423329AbWJaOGK (ORCPT ); Tue, 31 Oct 2006 09:06:10 -0500 Message-ID: <4547584F.6000702@rtr.ca> Date: Tue, 31 Oct 2006 09:06:07 -0500 From: Mark Lord User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Jan Engelhardt Cc: Zachary Amsden , Linux Kernel Mailing List Subject: Re: 2.6.18 is problematic in VMware References: <45463B7D.8050002@vmware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1798 Lines: 42 Jan Engelhardt wrote: >>> I have observed a strange slowdown with the 2.6.18 kernel in VMware. This >>> happened both with the SUSE flavor and with the FC6 installer CD (which I >>> am trying right now). In both cases, the kernel "takes its time" after the >>> following text strings: >>> >>> * Checking if this processor honours the WP bit even in supervisor mode... >>> Ok. >>> * Checking 'hlt' instruction... OK. >>> >>> What's with that? >> Thanks. It is perhaps the jiffies calibration taking a while because of the >> precise timing loop. Are you reasonably confident that it is a regression in >> performance over 2.6.17? > > Yes. I am not exactly sure if it's something in jiffies calibration > (because of the 'WP bit/supervisor' thing too), so maybe I thought it > was the newly-introduced SMP alternatives. I gotta check that. > >> The boot sequence is pretty complicated, and a lot of >> it is difficult / slow to virtualize, so it could just be alternate timing >> makes the boot output appear to stall, when in fact the raw time is still about >> the same. I will run some experiments. > > Booting with 'time' shows that the virtual time increases as usual, i.e. > > [ 9.00] checking if wp bit... > [15.00] next message here My experience with VMware on several recent processors (mostly P-M family) is that it crawls unless I force this first: echo 1 > /sys/module/processor/parameters/max_cstate So I use a wrapper script around VMware (workstation) to save max_cstate, set it to 1, and restore it again on exit. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/