[Pan-users] Re: Reproducible crash retrieving headers in million-header group

[Duncan]

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