linux-kernel - Re: 2.6.18 is problematic in VMware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Oct 2006 09:06:07 -0500
From:	Mark Lord <lkml@....ca>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
Cc:	Zachary Amsden <zach@...are.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.18 is problematic in VMware

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/