[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Retrieved]Re: Re: Finalize install questions



Ron Johnson wrote:
On Sun, 2004-12-05 at 11:01 -0700, Robert LeBlanc wrote:
 I guess I would have to
run tests to see. Another problem is that these programs can be memory
hogs and the nodes only have 512 MB of RAM which is another concern.
Lack of sufficient RAM seems like a much bigger issue than 32 vs 64.

32 vs 64 choice has no effect on a low RAM condition except as below.

The most important thing, it seems to me, is to verify whether you really are limited by available memory (i.e. whether the nodes are actively swapping) by looking at the virtual memory statistics. If your compute process has a working set size that is comparable to your system memory, or larger, you need to mitigate the impact of that. In addition to adding memory (until you hit the motherboard limits),
you can use multiple swap devices and/or a distributed network swap.

If your processes have a working set size that exceeds 25% of the virtual address space available on a 32 bit machine, you may find that the authors wanted to allow for an allocated memory footprint that might exceed the 2GB available on a standard kernel ... and thus put in a userspace paging algorithm that read/writes against a disk file.

If you've got such an algorithm in there, try seeing whether it can be disabled for 64 bit code. If so, this will reduce your memory needs. The reasoning is that program with a userspace pager, which is also hitting the kernelspace pager, tends to have data in four places:
* Real memory, mapped in userspace
* Swapspace, possibly stale due to a read()
* Backing store file
* Kernel file and/or disk cache of the backing store

If you can eliminate the userspace pager, even if you use mmap() of the backing store file instead of anonymous swap, you directly eliminate one of the in-memory copies of the data as well as half of the swap I/Os. Avoiding the pointer accesses for the userspace pager speeds things up because the code always has the data directly accessible in memory.

If you don't have a userspace swapper, there is little that 64 bit will gain you in calculation speed that could counteract the slightly larger memory footprint and the increased swap rate that is a direct consequence thereof.

Hope that helps ...



Reply to: