Red Hat Bugzilla – Bug 437914
RFE: Yum 32bit for installer? -- as 64bit uses twice as much memory
Last modified: 2008-10-18 06:44:41 EDT
Description of problem:
Checking process information on anaconda during a Fedora 9 install of 1992
packages shows 822684kB peak address space usage and (over a handful of samples)
about 490000kB RSS. A companion anaconda process appears to be using about
240MB address space also.
Version-Release number of selected component (if applicable):
Fedora 9 alpha
Install Fedora 9 alpha x86_64 and select as many packages as possible to install.
Steps to Reproduce:
Much less memory should be consumed by the installer.
This is likely the python object size on x86_64 hurting us again. Reassigning
to yum so they can verify that opinion.
It almost certainly doesn't help, 800MB VSZ and 400MB RSS is still a lot
though, most of the tests/fixes I did leading upto Fed-9 showed a Fed-8 =>
Fed-9 upgrade taking about half of that (depending on what repos. you had
enabled) ... is anaconda doing anything like creating two YumBase instances? Or
having a lot of repos. with data in them?
In all the testing I've done 64bit python seems to take roughly 4x the memory
as 32bit python ... so if we install via. a 32bit python/libs. we'd probably get
200MB VSZ / 100MB RSS ... but it's probably too late for even that?
 We had to backout some of the memory fixes due to unicode issues, but
nothing that would give 2x usage.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
(In reply to comment #2)
> In all the testing I've done 64bit python seems to take roughly 4x the memory
> as 32bit python ... so if we install via. a 32bit python/libs. we'd probably get
> 200MB VSZ / 100MB RSS ... but it's probably too late for even that?
Could we try this for F10, or is it too late for that?
much too late, I think
Are you sure that the 4x VSZ isn't really due to the reserved mappings:
After I posted comment #2 I did some more investigation, and found out some more data: http://illiterat.livejournal.com/4615.html is the basic summary.
Reserved mappings are a big part of the problem, but there are other things like mapping all of locale-archive.
Which basically make VSZ worthless on x86_64, so I think we should just concentrate on RSS ... which is pretty close to the "expected" 2x over .i386.
Doing this just for the installer is not going to happen. It would have to be generally done for the distro as a whole. We're trying to reduce the number of special case hacks in the installer, not add whole new levels of insane ones.
So to expand on that, after speaking with Jeremy, we have these problems:
1. Parts of the installer _must_ be in .x86_64, as they speak to the kernel (think modprobe) ... so we can't just use a full .i386 stage2.
2. There is no full multilib. python, so we can't just pull in the .i386 bits from the .x86_64 tree.
3. Pulling in bits of the installer from the .i386 and bits from the .x86_64 tree, is insanity.
4. Having _just_ a python.i386 in the x86_64 tree wouldn't work because then python extensions on .x86_64 programs won't work (apache/x-chat/etc.)
...so the only possible solution is to have a full multilib. python in Fedora, and then anaconda could just choose the .i386 version, but that is non-trivial and probably has no chance of happening until we have at least one full time python maintainer working with upstream (probably more).
(In reply to comment #9)
...so the only possible solution is to have a full multilib. python in Fedora,
> and then anaconda could just choose the .i386 version, but that is non-trivial
> and probably has no chance of happening until we have at least one full time
> python maintainer working with upstream (probably more).
And even then, it's *extremely* unlikely because then anaconda would be using a different python on x86_64 than everything else that we ship which all but guarantees weird bugs that are seen nowhere other than the installer. And really, better ways to spend time than tracking down things like that.