Ron Johnson posted on Sun, 01 Aug 2010 05:49:04 -0500 as excerpted: > Could you be running out of "process space"? > > With a 32-bit kernel, you only get approx 1.9GB of RAM per process. > Running a 64-bit kernel, though, even with a 32-bit userland, > gives each process 3.9GB.
Good question. I'm so used to amd64 I wasn't thinking of it, but you're absolutely right to ask the question (assuming the user's still on 32-bit, which is getting more and more legacy, these days, except in the netbook or embedded realm). FWIW, tho, the x86 32-bit Linux kernel does let you choose how the 32-bit virtual address space (4 gigs total) is divided. The choices are 3G/1G user/kernel split, 2G/2G, or 1G/3G. IDR which is the default, but there's actually five choices (not three), as for 3G/1G there's an additional choice for a full gig low memory, and with 2G/2G, there's another choice as well, for a full 2G low memory (tho these extra choices are disabled if the 64-gig high-memory option is chosen, leaving only the three, but they're available with the no-high-mem and 4-gig-options). These options are found in the processor type and features section, memory split option, altho the help says it depends on experimental and embedded options also being turned on, or you won't see it. When I got my Atom netbook, limited to 32-bit x86, I upgrade-maxed out the memory to 1.5 gigs (from the default half gig soldered on the mobo, there was a single slot, but the board wasn't setup to recognize more than a 1- gig stick, so a 2-gig stick wouldn't work, people tried), and decided to switch to the 2G/2G mode for maximum virtual memory flexibility, so I do know about it, tho I do tend to forget about it unless someone mentions they're running a netbook, or otherwise mentions it's 32-bit. So each process on 32-bit x86 is allowed between just under a gig, and just under 3 gigs, of virtual memory, depending on where the configured memory split is located. But if the user's still on 32-bit, given we're looking at memory in the gigs, here, it may indeed be that this is the cap being hit, and the user will need a kernel configured to 2G/2G or 3G/1G in ordered to load the full group. (Hopefully the 3-gig user option is enough... I'd think it should be, even with millions of overviews, with the better scaling in the pan-C++ rewrite starting with v0.90.) -- 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