A Simple SysV Shared Memory Load Generator

Again, I wrote a stupid program.

This time, I wanted to see the so called memory access cost under virtualized environments like VMware or Xen.
From another point of view, I wanted to see if large page support really improves business application performance such as PostgreSQL running on top of VMware especially.

Thus, I read LINUX_SRC/Documentation/vm/hugetlbpage.txt and began to write a (stupid :o) program which generates various memory work load using SystemV IPC shared memory.
The program, shmload, is available here as usual, and I was a bit surprised comparing results of large page enabled and normal ones on top of Centos 5.1 and VMware Workstation 6 running on WindowsXP.
In the ultimate case where the whole share memory segment is accessed via only one memset() API call, a large page enabled test with a 4MB share memory segment performed 20% better than a test without large page. Here, 20% means that the elapse time was shorter than the test without large page by 20%.

This could explain the performance degradation I saw at work, and I'm going to try the program there next week. :)

BTW, here are other issues I felt working on the stupid work.

• I want to use PostgreSQL for RDBMS at first, and it does not have large page support at this moment. :( Thus, my next work could be a patch for enabling large page support in PostgreSQL (on Linux).
• Xen does not have large page support at this moment. Thus, the only resolution is buying servers with AMD RVI enabled processors. I'm wondering why they do not support large page.
• Note on 2008/08/09. I found patches adding large page support on xen-devel ML.
  
• In case of Linux, a large page is handled as an unpageable page. In other word, a large page is locked down. Oracle looks like using large page, and I'm feeling it could potentially cause peformance problem.