Ron Johnson posted on Tue, 29 Mar 2011 03:09:22 -0500 as excerpted: > It's 32-bit. Running "top" clearly shows pan's memory usage (RES) > growing and growing. At about 3GB (a processes' address space in x86) > it barfs.
FWIW, on Linux that's a kernel option (with 2.6 kernels, anyway). With the 4-gig limit, the kernel/userspace split can be set to 3G/1G, 2G/2G, or the default 1G/3G. Additionally, there's a somewhat less efficient mode that sets 4G/4G, thus allowing access to (almost) a full 4-gig userspace (and a full 4G kernelspace, thus significantly reducing low memory pressure on 32G+ physical memory systems), but at the cost of switching memory pagetables and doing TLB flushes at every usercode/kernelcode switch. So it's possible to up that ~3GB to ~4GB. (There's a few MB worth of buffers of commonly mapped space between the two modes, so it's not /quite/ 4GB.) Whether it's worth the additional overhead I don't know... If you've >16G of physical memory, it likely is, and almost certainly is with >32G physical memory, due to the reduction in low-memory pressure, but under 16G... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
