Bug 173470
Summary: | ia32el service takes too much of memory | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Vaibhav Khanduja <vaibhav.khanduja> | ||||||||||||
Component: | ia32el | Assignee: | Petr Machata <pmachata> | ||||||||||||
Status: | CLOSED WONTFIX | QA Contact: | |||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||
Priority: | medium | ||||||||||||||
Version: | 3.0 | CC: | eric.lin, mnewsome, yoav.zach | ||||||||||||
Target Milestone: | --- | ||||||||||||||
Target Release: | --- | ||||||||||||||
Hardware: | ia64 | ||||||||||||||
OS: | Linux | ||||||||||||||
Whiteboard: | |||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||
Clone Of: | Environment: | ||||||||||||||
Last Closed: | 2007-10-19 18:50:51 UTC | Type: | --- | ||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||
Documentation: | --- | CRM: | |||||||||||||
Verified Versions: | Category: | --- | |||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
Embargoed: | |||||||||||||||
Attachments: |
|
Description
Vaibhav Khanduja
2005-11-17 12:28:21 UTC
Created attachment 121180 [details]
Test Prgram
Created attachment 121181 [details]
Sample program executes the script
if i understand correctly, the problem that you see is with the memory allocated about 4G. is this right ? if so, then please keep in mind that ia32el is a piece of software. it is loaded to memory and uses memory for its own purposes. i'm not sure there is a way to avoid these need for extra memory. thanks, yoav. Hi Yoav, I can understand that, if there is software it would take memory. But when it comes to actually deploying software in production environment it becomes difficult to have applications taking so much of memory. I would request you to please look the piece of code sent by me and if nothing else suggest a workaround; 4GB with such a small piece of code is something which worries me. Thanks, Vaibhav Khanduja i made a mistake - i meant to say 'above 4G', not 'about 4G', meaning that the extra memory is mapped at addresses higher than 4G. sorry for the confusion. i see the test case with ia32el consumes about 45MB. from our experience this is expected. i would expect to see the same memory-footprint even for running 'hello world'. please remember - the program that really executes is ia32el, which is quite a large application, not the ia32 binary. thanks, yoav. Would it be possible for you to somehow instrument the service and see if the memory consumption can be tunned a bit? Apart from this, with what confidence level can you say that the memory consumption would remain same if the service is kept running over a period of time, with more than one program making use of the service? thanks, Vaibhav Khanduja we are continuously working on improving ia32el. memory footprint is one of the factors we try to improve. given your input, we will put more focus on this specific factor now. there is however one point that skipped my eyes before, this is the allocation of 10M at address 40240000. we will investigate this issue. as for your second question - it has two parts really : about many programs running with ia32el - there are parts in libia32x.so and ia32exec.bin that are not writable. these parts (~7M) will be shared among all the ia32el processes in the system. all the other parts will not be shared. about running for a long period of time - there is a known problem of memory leak in libia32x.so, which is fixed in the version that will be shipped with EL3U7/EL4U3. we don't know of any other such issue. We recheked the issue with the large allocation below the ia32 stack - running the attached test case on native ia32 EL3 machine gives the same amount of mapping. as for running the test on ipf machine with ia32el disabled - we usaully compare ia32el with native ia32, and not with the hw emulation on ipf. nevertheless, we repeated this test with the hw emulation and got same results in some of the runs. the memory consumption was as read from /proc/*/maps file was not consistent in all runs, but again - in some of the runs it showed the same amount of allocated memory. will it be possible for you to verify our findings ? thanks, yoav. Would it be possible for you send the version of ia32el service or in patch form, which has fixed the memory leak? Regards, Vaibhav Khanduja Hi Yoav, I have some more data for you. I am attaching another sample program which periodically logs its resident stack size in a file. The program when executed with the service enabled the resident stack size tends to increase more frequently as compared to when the program is executed without service being enabled i.e. using the kernel emulation. I compiled this program on a Debian 3.0 x86 box with kernel 2.4.9-7. The program was executed on Redhat 3.0 kernel 2.4.21-38.EL IA64 with ia32el-1.3- 1.EL3 as the service version. Logs are also attached along with the program. Thanks, Vaibhav Khanduja Created attachment 125081 [details]
Resident Stack Size Checking Program
Created attachment 125082 [details]
Logs when service is on
Created attachment 125083 [details]
Logs when service is down
Hi, Vaibhav, Thanks for your information. I will take over Yoav for this work. I will start to investigate and keep you updated Eric. This bug has been opened for more than a year now, with no clear progress. Is this even still an issue? There has been one new release since then. This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you. |