Kevin Day wrote:
> On Mar 6, 2010, at 12:05 AM, Daniel O'Connor wrote:
> Yeah, sorry for not mentioning that I had tried this and didn't see any
> change, so I thought I was on the wrong track.
>
> # sysctl hw.acpi.cpu.cx_lowest=C3
> hw.acpi.cpu.cx_lowest: C1 -> C3
>
> but it doesn't look like i
On 03/05/10 20:14, Kevin Day wrote:
>
> Recently I bumped into something very weird. In some CPU heavy workloads,
> FreeBSD ran faster inside VMware's ESX hypervisor than it did running
> natively on bare metal. Simple pure CPU applications (such as "openssl
> speed") would run 10-30% faster on
On Sat, 6 Mar 2010, Kevin Day wrote:
> > ISTR FreeBSD defaults to a very conservative setting here so you
> > may have to set it manually.
>
> Yeah, sorry for not mentioning that I had tried this and didn't see
> any change, so I thought I was on the wrong track.
OK.
> Is the note about adding hi
On Mar 6, 2010, at 12:05 AM, Daniel O'Connor wrote:
> On Sat, 6 Mar 2010, Kevin Day wrote:
>> So, it seems that the VMware hypervisor is deactivating cores on the
>> CPU when idle, but FreeBSD itself isn't. Is anyone working on giving
>> FreeBSD's idle loop/scheduler the ability to go into deeper
On Sat, 6 Mar 2010, Kevin Day wrote:
> So, it seems that the VMware hypervisor is deactivating cores on the
> CPU when idle, but FreeBSD itself isn't. Is anyone working on giving
> FreeBSD's idle loop/scheduler the ability to go into deeper sleep
> states? It seems this would have more than just a
Recently I bumped into something very weird. In some CPU heavy workloads,
FreeBSD ran faster inside VMware's ESX hypervisor than it did running natively
on bare metal. Simple pure CPU applications (such as "openssl speed") would run
10-30% faster on VMware. This seemed very counterintuitive, un
6 matches
Mail list logo
