[ale] Procinfo

[Michael Trausch]

It seems nonsensical to me.  Yes, a slightly larger disk and RAM footprint
is required. That would be because pointers are 64 bit; there is no way to
not have some growth. But there are also more registers and the like which
means that compilers (both traditional and JIT) can create more efficient
code in many situations.

--
Sent from my phone... a G2 running CM7 nightlies!
On Feb 14, 2011 2:13 PM, "Scott McBrien" <smcbrien at gmail.com> wrote:
> Sorry about the misfire earlier, stupid phone!
>
> I think using 32bit kernels for VMs running on 64 bit CPUs is a bit silly.
The only memory consumption issues I can think of would be the negative,
especially for large memory consuming programs running on the VMs. Maybe the
recommendation is based on using a specific hypervisor. For KVM, this is
certainly not the case.
>
> -Scott
>
> On Feb 14, 2011, at 1:46 PM, "Damon L. Chesser" <damon at damtek.com> wrote:
>
>> On Mon, 2011-02-14 at 10:13 -0500, Tim Watts wrote:
>>> I also get a different set of flags between a virtual cpu and the
>>> physical one. Is there someplace where all those flags are documented?
>>
>> You might well, the "virtual cpu" *is* different from the actual cpu.
>> And just because you have a x64 phys. proc, does not mean you have a x64
>> virt. proc. It would all depend on how the admin set up the virtual
>> environment as well as the software used to virtualize. Many people
>> think you should only use x32 for virt. guest (proxmox recommends this,
>> for example) because x32 is less demanding on memory resources for the
>> same applications when compared to x64.
>>
>>>
>>>
>>> On Mon, 2011-02-14 at 10:03 -0500, Jim Kinney wrote:
>>>> If lm is present it's a 64 bit capable system. if not it's 32.
>>>>
>>>> unless a virtual machine is weird.
>>>>
>>>> On Mon, Feb 14, 2011 at 10:01 AM, Geoffrey Myers
>>>> <lists at serioustechnology.com> wrote:
>>>>> Jim Kinney wrote:
>>>>>> On Mon, Feb 14, 2011 at 9:23 AM, Geoffrey Myers
>>>>>> <lists at serioustechnology.com> wrote:
>>>>>>
>>>>>>>> uname -a will work.
>>>>>>> Is this not just showing you what your kernel is? I can run a 32 bit
>>>>>>> kernel on a 64 bit machine.
>>>>>>>
>>>>>>>
>>>>>> yep. The solution was /proc/cpuinfo | grep flags | grep " lm ". D.
>>>>>> Chesser had the best solution.
>>>>>
>>>>> Hmmm, I don't see it. Maybe because I'm on a virtual?
>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Until later, Geoffrey
>>>>>
>>>>> "I predict future happiness for America if they can prevent
>>>>> the government from wasting the labors of the people under
>>>>> the pretense of taking care of them."
>>>>> - Thomas Jefferson
>>>>> _______________________________________________
>>>>> Ale mailing list
>>>>> Ale at ale.org
>>>>> http://mail.ale.org/mailman/listinfo/ale
>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>> http://mail.ale.org/mailman/listinfo
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>
>> --
>> Damon
>> damon at damtek.com
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110214/d259b308/attachment.html