Operating System - HP-UX
1833863 Members
2005 Online
110063 Solutions
New Discussion

is eqmemsize a valid way to spoof less RAM?

 
Mark Hudson_1
New Member

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?
'twas brillig and the slithy toves...
3 REPLIES 3
James Murtagh
Honored Contributor

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.
Olivier ROBERT
Frequent Advisor

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
Mark Hudson_1
New Member

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).
'twas brillig and the slithy toves...