Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 09/15/2010 11:35 AM, Richard Pieri wrote: > Some high performance database engines wire their cache (ex: Cach=E9). = Virtual machine monitors wire portions of the memory that they manage (e= x: VMware Fusion, probably VMware Workstation but I don't have it handy t= o see). Some Java VMs wire their heap allocations (ex: Java HotSpot VM),= which is why I brought it up in the first place. > > There's a lot more wired memory in use out there than you suspect, I th= ink. Few apps wire all of their memory allocations but many wire the sla= bs critical to performance. In those cases, wiring in memory makes a lot of performance sense, but those same systems, especially database servers, need a very high up time. Virtual machines are interesting in they have guest operating systems that also do paging. Years ago I worked with IBM's VM370 with OS/VS1 as the guest. VS1 was not very good in the paging and spooling area. We could tell VM370 to manage VS1's page faults. We also found that double spooling (letting VM370 manage the printers rather than VS1) gave us better performance (eg. we got our payroll checks out faster). We also found that the throughput of VS1 under VM370 (with several users using CMS) was better than running VS1 native with the same batch load, in this case payroll. The bottom line is the reboot policy should be based upon what you are running. Additionally, for an application to wire memory on Linux and most Unix systems, the app must be a privileged app. A virtual machine manager that has a kernel driver can do this. Additionally, the kernel may retain some applications and libraries in physical memory after they exit for a period of time. This feature was added because Unix/Linux commands are generally small and frequently used. --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |