libc6 requirements for Linux VM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

libc6 requirements for Linux VM

K K Subbu
 
Hi,

This is continuation of a discussion at etoys-dev
 http://lists.squeakland.org/pipermail/etoys-dev/2010-October/005949.html

Essentially, 4.x Linux VMs may fail with an error:
 
Could not load library: /lib/libc.so.6: version `GLIBC_2.7' not found

This is due to their dependency on libc6-2.7 or later. This version shipped in
Ubuntu 8.04+ and kernels 2.6.24+. Machines with 256MB RAM running perfectly
well on Ubuntu 7.10 became terribly slow when upgraded to 8.04 (google for
"ubuntu hardy slow"). Linux kernel degraded poorly when faced with memory
pressure caused by increased working set of 8.04. People with 256MB RAM
systems (e.g. schools) could not upgrade to distros with libc6 v2.7+ without
upgrading their hardware.

XOs have 256MB RAMs and so do virtual machines that run in qemu or kvm. So the
increased requirement may affect these deployments.

Has anyone faced this issue in Squeak v4.1 on production machines?

Subbu
Reply | Threaded
Open this post in threaded view
|

Re: libc6 requirements for Linux VM

David T. Lewis
 
On Fri, Oct 15, 2010 at 11:09:36PM +0530, K. K. Subramaniam wrote:

>  
> Hi,
>
> This is continuation of a discussion at etoys-dev
>  http://lists.squeakland.org/pipermail/etoys-dev/2010-October/005949.html
>
> Essentially, 4.x Linux VMs may fail with an error:
>  
> Could not load library: /lib/libc.so.6: version `GLIBC_2.7' not found
>
> This is due to their dependency on libc6-2.7 or later. This version shipped in
> Ubuntu 8.04+ and kernels 2.6.24+. Machines with 256MB RAM running perfectly
> well on Ubuntu 7.10 became terribly slow when upgraded to 8.04 (google for
> "ubuntu hardy slow"). Linux kernel degraded poorly when faced with memory
> pressure caused by increased working set of 8.04. People with 256MB RAM
> systems (e.g. schools) could not upgrade to distros with libc6 v2.7+ without
> upgrading their hardware.
>
> XOs have 256MB RAMs and so do virtual machines that run in qemu or kvm. So the
> increased requirement may affect these deployments.
>
> Has anyone faced this issue in Squeak v4.1 on production machines?

Well I certainly noticed this on my own old laptop (but I compile my
own VM's and did not pay much attention to it). Certainly we should
find a way to continue providing working VMs for XOs and for older
PCs in schools.

A couple of questions to clarify the issue:

For XOs and for all Etoys users, the images are not closure enabled,
and therefore only the traditional interpreter VM (not Cog) is an
issue at this time. Thus for the next round of VMs to be released
(timing aligned with Squeak 4.2 release), there is no need to provide
a Linux Cog VM compiled with the older libraries. Is this correct?

I know that there is an Etoys release being prepared right now. What
is the timeline for finding a solution to this issue?

Thanks for bringing this up.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: libc6 requirements for Linux VM

K K Subbu
 
On Saturday 16 Oct 2010 3:09:02 am David T. Lewis wrote:
> For XOs and for all Etoys users, the images are not closure enabled,
> and therefore only the traditional interpreter VM (not Cog) is an
> issue at this time. Thus for the next round of VMs to be released
> (timing aligned with Squeak 4.2 release), there is no need to provide
> a Linux Cog VM compiled with the older libraries. Is this correct?
The defect has to do with any VM linked against libc6-2.7 or later running in
256MB machines with disks. It would apply to Cog VM too. The manifest behavior
is responsiveness that goes from millisecs to seconds :-( :-(. We have to make
a special version for older configurations.
> I know that there is an Etoys release being prepared right now. What
> is the timeline for finding a solution to this issue?
Unknown at present. The defect is not in Etoys but in linux kernel. The defect
is very tricky and triggers a fault only during disk i/o operations under low
memory conditions. It was tracked down only in Dec 2009. Those who are
interested in kernel and i/o scheduling may want to follow the detective trail
in http://lkml.org/lkml/2009/12/7/237 thread.

Subbu