Re: Experiences with 7.0-CURRENT and vmware.

Kris Kennaway wrote:
> On Thu, May 10, 2007 at 08:24:18PM -0700, Garrett Cooper wrote:
>> Kris Kennaway wrote:
>>> On Thu, May 10, 2007 at 08:14:28PM -0700, Garrett Cooper wrote:
>>>> Kris Kennaway wrote:
>>>>> On Thu, May 10, 2007 at 08:44:48PM +0000, Darren Reed wrote:
>>>>>> On Thu, May 10, 2007 at 03:41:44PM -0400, Kris Kennaway wrote:
>>>>>>> On Thu, May 10, 2007 at 12:54:45PM +0000, Darren Reed wrote:
>>>>>> ...
>>>>>>>> In another reply it was "hint.apic.0.disabled=1".
>>>>>>>> My current loader.conf:
>>>>>>>>
>>>>>>>> vm.kmem_size=536870912
>>>>>>>> vm.kmem_size_max=536870912
>>>>>>>> unset acpi_load
>>>>>>> acpi_load="NO" to disable the module
>>>>>>>
>>>>>>>> hint.acpi.0.disabled=1
>>>>>>>> hint.apci.0.disabled=1
>>>>>>> dunno what apci does :)
>>>>>>>
>>>>>>>> hint.acpi.0.disabled="1"
>>>>>>> This is the one that should work.  Can you confirm that you see it in
>>>>>>> the loader environment by doing 'show'?
>>>>>> ok.  I modified my loader.conf to be:
>>>>>>
>>>>>> hint.acpi.0.disabled="1"
>>>>>> vm.kmem_size=536870912
>>>>>> vm.kmem_size_max=536870912
>>>>>> vfs.zfs.arc_max=402653184
>>>>>>
>>>>>> and now ACPI is didsabled when the kernel boots :-)
>>>>>>
>>>>>> Is it possible for parsing errors of this file to generate errors?
>>>>>> And maybe pause for a few seconds so they can be read?
>>>>> I guess all things are possible with forth.
>>>>>
>>>>>> When I was modifying the loader.conf, I was looking for errors on
>>>>>> bootup but regarding getting acpi vs apci vs apic right, I never
>>>>>> saw any.  My experience also tells me that errors seem to quietly
>>>>>> stop the rest of the file being parsed or...?
>>>>>>
>>>>>>>> # sysctl kern.timecounter.hardware="ACPI-fast"
>>>>>>>> kern.timecounter.hardware: ACPI-safe
>>>>>>>> sysctl: kern.timecounter.hardware: Invalid argument
>>>>>>> kern.timecounter.choice
>>>>>> When I tried to set this with sysctl, I got told it was read-only.
>>>>>> The next step was to put it in loader.conf but now ACPI *is* disabled :)
>>>>> Sorry, .hardware was the correct one.  I don't know why you are unable
>>>>> to set it at runtime:
>>>>>
>>>>> xor# sysctl kern.timecounter.hardware=TSC
>>>>> kern.timecounter.hardware: ACPI-fast -> TSC
>>>>> xor# sysctl kern.timecounter.hardware=ACPI-fast
>>>>> kern.timecounter.hardware: TSC -> ACPI-fast
>>>>>
>>>>> Kris
>>>> I'm not sure why but it isn't settable with VMWare 1.03 server either.
>>> Maybe there are no other valid choices provided by vmware.
>>>
>>>> I gave the Intel ACPI one a shot though and I haven't seen any adverse 
>>>> effects.. yet. It is true that the higher the number, the faster the 
>>>> synchronization or the inverse?
>>> It's a "quality factor" that tries to estimate and rank the various
>>> properties of time counters (higher = better).
>> Basically sample rate?
> 
> I think things like accuracy, query cost, stability.
> 
> Kris
> 

Clock skew is a really big issue with VMWare and multiple cores. I'm 
running amd64, and I've noticed that if I don't sync the clocks 
regularly and run CPU intensive compiles, the clocks will skew a lot 
(10~30 minutes if running buildworld over a 1.5 hour period), and when I 
try and reboot the machine it fails to notify the running daemons that 
they need to be killed.

For now I'm switching my VM back to single core, but it should be noted 
that this is a big issue and multicore vmware should not be tried (at 
least with FreeBSD, as much as other OSes), because of the realtime 
clock syncing problem.

-Garrett