All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <lkml@rtr.ca>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: Zachary Amsden <zach@vmware.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.18 is problematic in VMware
Date: Tue, 31 Oct 2006 09:06:07 -0500	[thread overview]
Message-ID: <4547584F.6000702@rtr.ca> (raw)
In-Reply-To: <Pine.LNX.4.61.0610310857280.23540@yvahk01.tjqt.qr>

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

  reply	other threads:[~2006-10-31 14:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-29  9:55 2.6.18 is problematic in VMware Jan Engelhardt
2006-10-30 17:50 ` Zachary Amsden
2006-10-31  7:59   ` Jan Engelhardt
2006-10-31 14:06     ` Mark Lord [this message]
2006-10-31 17:20       ` Jan Engelhardt
2006-11-01  2:33         ` Zachary Amsden
2006-11-03  8:07           ` Jan Engelhardt
2006-11-02  8:21       ` S.Çağlar Onur
2006-11-02  8:13   ` S.Çağlar Onur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4547584F.6000702@rtr.ca \
    --to=lkml@rtr.ca \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zach@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.