HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: is eqmemsize a valid way to spoof less RAM?
Operating System - HP-UX
1833873
Members
1677
Online
110063
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-07-2003 10:33 AM
04-07-2003 10:33 AM
is eqmemsize a valid way to spoof less RAM?
My situation is:
1. test a memory-sensitive piece of software on a test/dev machine before deploying it to production.
2. the test/dev machine has significantly more RAM than the production box.
My two choices seem to be
1. Physically remove the RAM
2. spoof less RAM via software/config settings
I am leaning towards the software method, but want to get feedback/caveats.
My idea is to tune the eqmemsize kernel parameter --normally used to reserve memory for DMA. It defaults to only 15 (4k pages) which is pretty small. Inflate it to artificially large, and it will be "roughly equivalent to removing the same amount of physical memory." as stated at http://docs.hp.com/hpux/onlinedocs/TKP-90202/00/00/75-con.html and deduceable from http://docs.hp.com/hpux/onlinedocs/939/KCParms/KCparam.EqMemSize.html
I tried it and the below results seem encouraging in that the "available" amount went down.
$ ssh hp008 /usr/local/bin/sudo dmesg \| grep Physical
Physical: 4194304 Kbytes, lockable: 3226648 Kbytes, available: 3707444 Kbytes
$ ssh hp010 /usr/local/bin/sudo dmesg \| grep Physical
Physical: 4194304 Kbytes, lockable: 3226664 Kbytes, available: 1610368 Kbytes
I am a bit worried that the "lockable" reported amount did not go down. Should I tune another param?
$ kmtune -q unlockable_mem defaults to 0 ... I wonder what tweaking this would do?
1. test a memory-sensitive piece of software on a test/dev machine before deploying it to production.
2. the test/dev machine has significantly more RAM than the production box.
My two choices seem to be
1. Physically remove the RAM
2. spoof less RAM via software/config settings
I am leaning towards the software method, but want to get feedback/caveats.
My idea is to tune the eqmemsize kernel parameter --normally used to reserve memory for DMA. It defaults to only 15 (4k pages) which is pretty small. Inflate it to artificially large, and it will be "roughly equivalent to removing the same amount of physical memory." as stated at http://docs.hp.com/hpux/onlinedocs/TKP-90202/00/00/75-con.html and deduceable from http://docs.hp.com/hpux/onlinedocs/939/KCParms/KCparam.EqMemSize.html
I tried it and the below results seem encouraging in that the "available" amount went down.
$ ssh hp008 /usr/local/bin/sudo dmesg \| grep Physical
Physical: 4194304 Kbytes, lockable: 3226648 Kbytes, available: 3707444 Kbytes
$ ssh hp010 /usr/local/bin/sudo dmesg \| grep Physical
Physical: 4194304 Kbytes, lockable: 3226664 Kbytes, available: 1610368 Kbytes
I am a bit worried that the "lockable" reported amount did not go down. Should I tune another param?
$ kmtune -q unlockable_mem defaults to 0 ... I wonder what tweaking this would do?
'twas brillig and the slithy toves...
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-07-2003 11:50 AM
04-07-2003 11:50 AM
Re: is eqmemsize a valid way to spoof less RAM?
Hi Mark,
Interesting test!
I suppose the big question is whether the system will start using the equivalently mapped memory if the available memory is very low - I don't think so, it would seem to contradict the kernel setting.
One possible problem I can see with the lockable memory being that high is if you have a large dynamic buffer cache, i.e. maximum close to available memory, you may get into a memory deadlock situation that I have seen a lot on small memory systems. You may also have a large difference is swap space available if you have psuedo swap enabled on the test server. However, as you implied lockable memory is just the value of physical memory minus unlockable memory. If unlockable_mem is set to 0 as in your case the system works it out, normally to ~75% of physical memory but you can change this no problem.
Even more of a headache is the fact the system allocates memory structures for each page of physical memory, for example the hpde or page directory entries. The structures may be quite small...I'll just check...
q4> sizeof(struct hpde)
030 24 0x18
ok only 24 bytes per page but if you have 1 million pages....you may need to factor these kind of things in, which is very hard.
You also may find the CPU performance on the test server suddenly improve if the cache contention is reduced by having so many pages equivalently mapped. Or is it the other way round? Anyway, there could be issues here that are hard to plan for.
I think what I'm saying is that taking the memory out would be the way to go! :-)
Regards,
James.
Interesting test!
I suppose the big question is whether the system will start using the equivalently mapped memory if the available memory is very low - I don't think so, it would seem to contradict the kernel setting.
One possible problem I can see with the lockable memory being that high is if you have a large dynamic buffer cache, i.e. maximum close to available memory, you may get into a memory deadlock situation that I have seen a lot on small memory systems. You may also have a large difference is swap space available if you have psuedo swap enabled on the test server. However, as you implied lockable memory is just the value of physical memory minus unlockable memory. If unlockable_mem is set to 0 as in your case the system works it out, normally to ~75% of physical memory but you can change this no problem.
Even more of a headache is the fact the system allocates memory structures for each page of physical memory, for example the hpde or page directory entries. The structures may be quite small...I'll just check...
q4> sizeof(struct hpde)
030 24 0x18
ok only 24 bytes per page but if you have 1 million pages....you may need to factor these kind of things in, which is very hard.
You also may find the CPU performance on the test server suddenly improve if the cache contention is reduced by having so many pages equivalently mapped. Or is it the other way round? Anyway, there could be issues here that are hard to plan for.
I think what I'm saying is that taking the memory out would be the way to go! :-)
Regards,
James.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-16-2003 10:01 AM
04-16-2003 10:01 AM
Re: is eqmemsize a valid way to spoof less RAM?
Hi Mark,
I have been looking for the same thing as you for some time, and someone even pointed me to your thread.
Finally, I got the solution, which is really easy, but undocumented, hence unsupported:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x128f19434a69d711abdc0090277a778c,00.html
Hope this helps!
Regards,
Olivier
I have been looking for the same thing as you for some time, and someone even pointed me to your thread.
Finally, I got the solution, which is really easy, but undocumented, hence unsupported:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x128f19434a69d711abdc0090277a778c,00.html
Hope this helps!
Regards,
Olivier
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-14-2004 12:05 PM
01-14-2004 12:05 PM
Re: is eqmemsize a valid way to spoof less RAM?
Unfortunately, some non-adventurous higher-ups mandated that we actually yank the RAM chips. Oh well.
Further Exploration
writing a simple program that "locks" some RAM--thus preventing it from being swappable.
$ kmtune -q unlockable_mem defaults to 0 ... I wonder what tweaking this would do?
Allocating a RamDisk would probably have a RAM-eating effect.
$ echo "total_lockable_mem/D" | sudo adb -k /stand/vmunix /dev/kmem
My [ITRC Q:] http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=191533
try using the -M option when launching the kernel (as per http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=47137 aka [longer]) e.g.
ISL> hpux -M 131072
This restricts physmem logically to 512 MB (131072 pages 4K each).
Further Exploration
writing a simple program that "locks" some RAM--thus preventing it from being swappable.
$ kmtune -q unlockable_mem defaults to 0 ... I wonder what tweaking this would do?
Allocating a RamDisk would probably have a RAM-eating effect.
$ echo "total_lockable_mem/D" | sudo adb -k /stand/vmunix /dev/kmem
My [ITRC Q:] http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=191533
try using the -M option when launching the kernel (as per http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=47137 aka [longer]) e.g.
ISL> hpux -M 131072
This restricts physmem logically to 512 MB (131072 pages 4K each).
'twas brillig and the slithy toves...
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP