On 12.02.2013, Reindl Harald wrote:
> and since all the guests are sharing the same host CPU
> it is unlikely that there are the same values over weeks
> if there is something relieable meassured because in this
> moment "boot time" is only for one of them while the others
> in full production lo
Am 12.02.2013 19:19, schrieb Heinz Diehl:
> On 12.02.2013, Reindl Harald wrote:
>
>> 2 different virtual machines, same host
> []
>> impossible that they have exactly the same loops per
>> timeslice on a host with 20 guests and that each of
>> their cores have the same is even more unlikely
On 12.02.2013, Reindl Harald wrote:
> 2 different virtual machines, same host
[]
> impossible that they have exactly the same loops per
> timeslice on a host with 20 guests and that each of
> their cores have the same is even more unlikely
It's calculated at boot time, on the same host as yo
Am 12.02.2013 18:33, schrieb Tom Horsley:
> On Tue, 12 Feb 2013 17:37:06 +0100
> Reindl Harald wrote:
>
>> you can not do this because you can hardly deploy packages
>> built this way on a i7-3770 (Ivy Bdrige) to a Xeon E5640
>> which is Westmere architecture without ending in "unknown
>> CPU in
On Tue, 12 Feb 2013 17:37:06 +0100
Reindl Harald wrote:
> you can not do this because you can hardly deploy packages
> built this way on a i7-3770 (Ivy Bdrige) to a Xeon E5640
> which is Westmere architecture without ending in "unknown
> CPU instruction" and random crashes and in the worst case
>
Am 12.02.2013 17:31, schrieb Heinz Diehl:
> On 12.02.2013, Reindl Harald wrote:
>
>> -O3 -march=corei7 -mtune=corei7 -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes
>> -fopenmp -mfpmath=sse
>
> You can do that more easily by "-march=native"
you can not do this because you can hardly deploy packa
Am 12.02.2013 17:29, schrieb Heinz Diehl:
> On 12.02.2013, Reindl Harald wrote:
>
>> is it hardcoded in the CPU?
>
> No.
>
>> is it measured?
>
> Yes. See init/calibrate.c in your kernel source, it's calculated as
> loops per timeslice. As far as I can see, it does no longer serve
> any pur
On 12.02.2013, Reindl Harald wrote:
> -O3 -march=corei7 -mtune=corei7 -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes
> -fopenmp -mfpmath=sse
You can do that more easily by "-march=native".
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://
On 12.02.2013, Reindl Harald wrote:
> is it hardcoded in the CPU?
No.
> is it measured?
Yes. See init/calibrate.c in your kernel source, it's calculated as
loops per timeslice. As far as I can see, it does no longer serve
any purposes and is eventually kept because of historical reasons.
--
On 12/02/2013 14:05, Reindl Harald wrote:
Am 12.02.2013 14:37, schrieb Gordan Bobic:
On 12/02/2013 13:24, Reindl Harald wrote:
that just tells that you can disable a lot of services
and overhead in a VM you would never do on bare metal
and it tells that the hypervisor can schedule IO much
mor
Am 12.02.2013 14:37, schrieb Gordan Bobic:
> So much experience, so little understanding...
BTW:
before you certify others little understanding fix your
webserver config with "expose_php=0" and "ServerTokens Prod"
Server: Apache/2.2.15 (Scientific Linux)
X-Powered-By: PHP/5.3.3
signature.a
Am 12.02.2013 14:37, schrieb Gordan Bobic:
> On 12/02/2013 13:24, Reindl Harald wrote:
>> that just tells that you can disable a lot of services
>> and overhead in a VM you would never do on bare metal
>> and it tells that the hypervisor can schedule IO much
>> more efficient as a generic kernel
On 12/02/2013 13:24, Reindl Harald wrote:
Am 12.02.2013 13:38, schrieb Gordan Bobic:
-O3 -march=corei7 -mtune=corei7 -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes
-fopenmp -mfpmath=sse
That just tells me you didn't push the machine to full saturation.
Virtualization takes resources, and you
Am 12.02.2013 13:38, schrieb Gordan Bobic:
>> -O3 -march=corei7 -mtune=corei7 -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes
>> -fopenmp -mfpmath=sse
>
> That just tells me you didn't push the machine to full saturation.
>
> Virtualization takes resources, and you cannot go faster by adding overh
On 12/02/2013 12:17, Reindl Harald wrote:
Am 12.02.2013 12:58, schrieb Gordan Bobic:
On 12/02/2013 10:46, Reindl Harald wrote:
means:
you buy much better hardware with more and faster CPU's
for a single device as you would buy for 20 machines
and most of the day one or two guests can allocate
Am 12.02.2013 12:58, schrieb Gordan Bobic:
> On 12/02/2013 10:46, Reindl Harald wrote:
>> means:
>> you buy much better hardware with more and faster CPU's
>> for a single device as you would buy for 20 machines
>> and most of the day one or two guests can allocate
>> most of the ressources on th
On 12/02/2013 10:46, Reindl Harald wrote:
Am 12.02.2013 11:01, schrieb Gordan Bobic:
On 12/02/2013 00:42, Reindl Harald wrote:
under real load the XEON is so much faster even
with the virualization overhead which is small
these days but still exists
Small as in un-noticeable if your VMs are
Am 12.02.2013 11:01, schrieb Gordan Bobic:
> On 12/02/2013 00:42, Reindl Harald wrote:
>> under real load the XEON is so much faster even
>> with the virualization overhead which is small
>> these days but still exists
>
> Small as in un-noticeable if your VMs are largely idling. Not that small
On 12/02/2013 00:42, Reindl Harald wrote:
Am 12.02.2013 01:17, schrieb Robert Moskowitz:
On 02/11/2013 06:07 PM, Reindl Harald wrote:
Am 11.02.2013 23:43, schrieb Robert Moskowitz:
Do I have this right?
since on a duo core system, /proc/cpuinfo reports both cores and a bogomips
number fo
On 11/02/2013 23:07, Reindl Harald wrote:
Am 11.02.2013 23:43, schrieb Robert Moskowitz:
Do I have this right?
since on a duo core system, /proc/cpuinfo reports both cores and a bogomips
number for each, that number is the
value for a core. Thus 'in theory' the bogomips for the unit is the
Am 12.02.2013 01:17, schrieb Robert Moskowitz:
>
> On 02/11/2013 06:07 PM, Reindl Harald wrote:
>>
>> Am 11.02.2013 23:43, schrieb Robert Moskowitz:
>>> Do I have this right?
>>>
>>> since on a duo core system, /proc/cpuinfo reports both cores and a bogomips
>>> number for each, that number is
On 02/11/2013 06:07 PM, Reindl Harald wrote:
Am 11.02.2013 23:43, schrieb Robert Moskowitz:
Do I have this right?
since on a duo core system, /proc/cpuinfo reports both cores and a bogomips
number for each, that number is the
value for a core. Thus 'in theory' the bogomips for the unit is t
Am 11.02.2013 23:43, schrieb Robert Moskowitz:
> Do I have this right?
>
> since on a duo core system, /proc/cpuinfo reports both cores and a bogomips
> number for each, that number is the
> value for a core. Thus 'in theory' the bogomips for the unit is the sum of
> the two values (the same
23 matches
Mail list logo
