Re: [Pan-users] Linux Pan crashes on exit on x64 system.

[Duncan]

Joe Zeff posted on Sat, 25 Mar 2017 15:59:12 -0700 as excerpted:

> On 03/25/2017 03:52 PM, Duncan wrote:
>> Is this x64 the newish unholy and problematic 64-bit/32-bit amalgam
>> that's 64-bit kernel and IIRC some kernel calls but otherwise 32-bit
>> userspace?
> 
> No.  I think that's called PAE, at least for Fedora.  It's a proper
> X86-64 bit system.

As Zan pointed out, it's x32 I was referring to with the unholy amalgam 
reference.

PAE is different.  It's still a normal 32-bit x86 system in general, but 
using the PAE feature of more modern x86 hardware to extend the total 
kernel-addressable address space to 64 GiB, up from the normal 4 GiB.

But per-process space remains stuck at 4 GiB total, with a usual 2 GiB 
userspace and 2 GiB kernelspace (2:2) split.  Using other kernel config 
options this split can be made 1:3 or 3:1, or with a bit more cost to 
kernel/userspace switching times, userspace and kernelspace can each be 
given their separate 4 GiB address spaces, but even with both PAE and 
separate user/kernelspace, a 32-bit process remains limited to 4 GiB 
userspace.

Full 64-bit removes that userspace limit, letting both userspace and 
kernelspace address huge amounts of memory well beyond anything even big 
corps tend to be able to afford at this point (tho AFAIK some are getting 
close to hitting the 40-bit hardware limit the original x86_64 hardware 
shipped with, using the other bits for other things, and I believe the 
present hardware limit has now been upped to 48 bits).

Running 32-bit processes on a 64-bit kernel ups the limit for the kernel 
(no more 64-GiB system limit as imposed by 32-bit but with PAE), so you 
can run more processes, but not for the still 32-bit processes.  Running 
full 64-bit processes as well ups the limit for them as well.

What my "unholy amalgam" x32 does is somewhat better than normal 32-bit 
x86 on an x86_64 kernel, as it allows the still 32-bit apps to use other 
hardware features (more hardware registers, etc) otherwise reserved for 
64-bit only due to having to maintain backward compatibility in the 32-
bit space, and they use some newer 64-bit kernel calls, but they're still 
limited to 32-bit address pointers and thus 4 GiB per app, not so much of 
a problem for most apps especially back when amd64 aka x86_64 was first 
introduced, but slowly becoming more of a problem as individual apps, now 
broken free of the previous 2-4 GiB address space limit of 32-bit, grow 
to sometimes take advantage of that available extra memory.

Which means it would have been great back in the day when most apps were 
still assuming 32-bit, and were yet to be ported to amd64/x86_64 anyway, 
but isn't so great now, since it means more porting costs now, for only a 
relatively small gain in lower per-app memory costs, and arguably a loss 
in terms of limits due to the reimposition of the 32-bit 4 GiB memory cap.

(Tho I'm not sure, arguably with the 64-bit x32 kernel not using PAE, if 
setup correctly, x32 apps might be able to use it, thus allowing per-app 
access, if at a slight overhead cost, to 64 GiB.  But I still think the 
cost and hassle aren't worth it since full x86_64 took over.)

And of course there's now arm64 coming on quite strong as well, with 
arguably more interest in porting to and supporting it than yet another 
x86 variant.

-- 
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