Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
Since 32 bits means that any machine with 1 GB more means HIGHMEM,
the number of non-embedded machines that should run 32-bit kernels
today is functionally the null set. Unfortunately Linux distros
have not properly promoted 64-bit kernels for 32-bit distros;
although pure 64 bits is better, it would be a *helluva* lot better
if people stuck on 32 bits for compatibility reasons had a saner
alternative.
-- H. Peter Anvin
Can people now accept that the reason we have rather more complex
models for security policy is because generally speaking these "oh
so simple" little magic switches don't actually work or solve any
real world problems.
-- Alan Cox(Log in to post comments)
Quotes of the week Posted Jan 21, 2010 5:15 UTC (Thu) by Per_Bothner (subscriber, #7375) [Link] I'm "stuck" on 32 bits not primarily for compatibility reasons, but even more because of memory. My laptop only has 3GB. When I tried a 64-bit distribution, I found myself running low on memory, and things ran noticeably slower. (I'm admittedly a-typical, trying to do Java software development on a laptop while also running Firefox, Thunderbird, etc.) I hope to switch to 64-bit when I get a new laptop.
Quotes of the week Posted Jan 21, 2010 5:56 UTC (Thu) by madscientist (subscriber, #16861) [Link]
I understood H. Peter's comment to mean that even for people who are using 32bit userspace for some reason, it makes good sense to run a 64bit kernel. On our embedded system we do exactly this: we run a 64bit kernel but have 32bit userspace. It does work well.
The problem we ran into is that tools that need to cross the userspace/kernel boundary are not always properly coded to work in this environment. For us, this came in the form of kexec/kdump; we couldn't get 32bit versions of these tools to work with our 64bit kernels. We ended up including a 64bit userspace library environment, to solve this problem.
Quotes of the week Posted Jan 21, 2010 6:06 UTC (Thu) by Per_Bothner (subscriber, #7375) [Link] I understood H. Peter's comment to mean that even for people who are using 32bit userspace for some reason, it makes good sense to run a 64bit kernel.I understand that, and I agree. I was just pointing out compatibility isn't the only reason for preferring 32-bit user-space; memory usage is another (as I'm sure you understand in an embedded environment). But selecting 32-bit Firefox and Java on an otherwise 64-bit distribution may be a good combination; I'll check that out that when I get around to trying Rawhide again.
Quotes of the week Posted Jan 21, 2010 15:32 UTC (Thu) by dmk (subscriber, #50141) [Link]
I don't quite understand. My laptop has 2 GB and i run a 64bit kernel. I can see no increased memory usage. Or am i not looking right?
Per_Bothner wrote:
Quotes of the week Posted Jan 21, 2010 8:34 UTC (Thu) by ekj (guest, #1524) [Link]
Sorta surprising to me actually. Yes, I get that pointers take twice as much space in 64-bit, but are there really so many of those that it makes a significant difference to the memory-usage of a typical application ?
Quotes of the week Posted Jan 21, 2010 10:47 UTC (Thu) by mpr22 (subscriber, #60784) [Link]
A non-intrusive doubly linked list uses three pointers per element. A non-intrusive binary tree uses four. So, given the general tendency to dynamic allocation of everything, I'd guess the answer is "yes".
Quotes of the week Posted Jan 23, 2010 15:02 UTC (Sat) by anton (guest, #25547) [Link] How do you count four pointers per element in your binary tree? I count three: left, right, element.In my experience doubly-linked lists are a nightmare, and it has also been a long time since I last used a binary tree (they are not that useful). However, in Java even a plain array usually needs one reference (aka pointer aka address) per element, and Java uses references in many other places as well, so it's quite conceivable that a 64-bit Java VM has a bigger footprint than a 32-bit JVM.
Quotes of the week Posted Jan 25, 2010 1:58 UTC (Mon) by ajf (subscriber, #10844) [Link] On the other hand, a 64-bit JVM doesn't necessarily need to use 64-bit object pointers. It can use "compressed" 32-bit addresses, which mitigates the issue somewhat.
Quotes of the week Posted Jan 25, 2010 13:08 UTC (Mon) by mpr22 (subscriber, #60784) [Link] C++'s
Quotes of the week Posted Jan 21, 2010 10:53 UTC (Thu) by epa (subscriber, #39769) [Link]
Isn't there some magic flag you can pass to gcc to make it use four-byte pointers even when compiling x86_64 code? Obviously they would need to be converted to eight bytes when calling external library functions, and obviously this would limit your process's maximum core size to four gigabytes or less.
Sort of like 'near' and 'far'?
four byte pointers Posted Jan 21, 2010 13:29 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
GCC doesn't get to decide whether (any of) your pointers "fit" into four bytes
Say you call the system allocator. You're a 64-bit process, so it is free to give you the value 0x801e780040. That won't fit in your 32-bit pointer. So, now what do you do with this value?
Of course you can re-design software to use array offsets instead of pointers, and by using 32-bit integers for the offsets but having 64-bit addresses you get to have billions of items in total, yet handles to those items cost only 4 bytes instead of 8. But the compiler can't do that for you, if you use pointers now, there is no static transformation that will reliably convert that to an array-offset representation.
If you run a 32-bit process on a 64-bit kernel, the system calls all ensure where necessary that you get 32-bit addresses and so this problem doesn't arise.
I guess GCC _could_ have a mode where you get a 32-bit process but it knows that your hardware is an x86-64, and so you can use a few extra instructions? But I don't see much point in that.
four byte pointers Posted Jan 21, 2010 17:07 UTC (Thu) by epa (subscriber, #39769) [Link] If you run a 32-bit process on a 64-bit kernel, the system calls all ensure where necessary that you get 32-bit addresses and so this problem doesn't arise.Not just a few extra instructions, but twice the number of registers, you still get 64-bit ints if you want them, and so on. I was imagining a special call 'malloc_32bit()' - to be implemented both in the C library and the kernel - which would guarantee to return an address in the lower 4 gigabytes of your process's logical address space (or fail, of course). As you say, 32-bit processes can run on 64-bit systems, so the functionality to return a low memory address must exist. This special 'small pointer' type could then be used in data structures such as linked lists which are pointer-intensive but need to be kept small. Of course, a 'small pointer' could be trivially cast to a 'large pointer', but not the other way around. Your suggestion of using array offsets would mean this technique could be used for any 4 gigabyte window of the address space, rather than just the bottom part. In principle, rewriting code to use offsets instead of pointers could also be done automatically by the compiler, but it's a lot more tricky to do the necessary checking that the wrong kind of pointers aren't mixed together.
four byte pointers Posted Jan 21, 2010 20:05 UTC (Thu) by RobSeace (subscriber, #4435) [Link] I was imagining a special call 'malloc_32bit()' - to be implemented both in the C library and the kernel - which would guarantee to return an address in the lower 4 gigabytes of your process's logical address space (or fail, of course).Couldn't you just use mmap() to accomplish that? You can give it the address you want the memory mapped at with MAP_FIXED... You'd just need to ensure nothing else is using that space already... Actually, scrap that: reading the man page, I see there's apparently now a MAP_32BIT, which guarantees giving you a pointer in the lower 2G of your address space... So, it seems what you want already exists!
four byte pointers Posted Jan 28, 2010 23:10 UTC (Thu) by efexis (guest, #26355) [Link]
There is actually a lot of support in this direction already, for the purpose (well, partially, amongst other reasons) of saving memory, and you will most likely already be running a fair amount of code that does this already, because when you use offsets rather than absolute addresses, a piece of code becomes usable regardless of where you load it into memory, which means you can share it in multiple address spaces, even if the same address isn't free for use in those seperate address spaces. Position Independant Code.
Remembering back to my earlier assembly days (granted things have changed much since then, but I think this bit's still true) the processors JUMP instructions generally use offsets where they can, as code will often only need to jump around short distances, and it's a waste to need to use a full address-width-word + space for the jump instruction. The same goes with values stored in the stack; you do a lot of work there with values not too far away from the stack frame top or bottom, an address already stored in a register, so you may as well use it, and it barely costs anything to do so, as the instruction prefix to switch between [address] and [base pointer + address] can be just a bit flipped in the instruction, or an extra byte, offset by the fact that you're saving a few bytes, and simple integer ADDs come almost for free in our modern fast multicore CPUs.
However I probably wouldn't fall off my chair should I learn that's horribly outdated :-)
four byte pointers Posted Feb 17, 2010 18:40 UTC (Wed) by oak (subscriber, #2786) [Link]
If you need to debug software which has an allocator using offsets
(fontconfig comes into mind...), it's quite painful because things like Valgrind cannot then verify whether there are still valid pointers to some allocated part of memory.
Quotes of the week Posted Jan 21, 2010 17:58 UTC (Thu) by madscientist (subscriber, #16861) [Link]
Almost every 64bit system out there today also provides a suite of 32bit libraries. If you want this all you have to do is compile your code as a 32bit application and run it on a 64bit system. That works just fine in almost every case (badly written code can flummox this of course: e.g. if you're trying to share binary data you need to be doing proper marshalling even between process on the same system, if they might differ in bitsize).
One of the projects I worked on switched from 32bit Red Hat EL 4 to 64bit Red Hat EL 5 as the base OS, and we continued to build our code as 32bit and it ran just fine.
Quotes of the week Posted Jan 21, 2010 11:42 UTC (Thu) by paulj (subscriber, #341) [Link] Yes there are. Pointers are very common in complex data structures. I posted a comparison of F12 32bit v F12 64bit memory usage to fedora-devel a while ago. I couldn't go further and do a more comprehensive comparison, unfortunately, as Qemu x86-64 doesn't seem to be robust enough (and even if it were, it's excruciatingly slow).
Quotes of the week Posted Jan 21, 2010 12:39 UTC (Thu) by nix (subscriber, #2304) [Link]
Interesting. F12 seemed fast enough under kvm 0.11.1-stable when I tried it. (It's still fast under 0.12.)
Quotes of the week Posted Jan 21, 2010 14:38 UTC (Thu) by paulj (subscriber, #341) [Link]
Yeah, KVM is nice and fast and worked great for testing F12 32bit. It can't help
with running a 64bit OS on a 32bit guest though - hence Qemu and full- emulation == terrifically slow (plus, it seems to be buggy, possibly).
Quotes of the week Posted Jan 21, 2010 16:05 UTC (Thu) by nix (subscriber, #2304) [Link]
Oh, you were trying to run -64 on -32? Yeah, I'd expect that to have received... limited testing, shall we say.
Quotes of the week Posted Jan 21, 2010 13:27 UTC (Thu) by alankila (subscriber, #47141) [Link]
-XX:+UseCompressedOops approximately the memory usage of Java on 64-bit systems. The downside is that only something like 32 GB of memory is accessible. (Really. I wonder why they don't just force this on by default.)
Quotes of the week Posted Jan 21, 2010 14:52 UTC (Thu) by alankila (subscriber, #47141) [Link]
approximately +halves the.
Quotes of the week Posted Jan 22, 2010 2:49 UTC (Fri) by mdz@debian.org (subscriber, #14112) [Link]
There are plenty of popular computers out there (most netbooks, for example)
which can boot a 32-bit kernel, but not a 64-bit kernel. These are not embedded systems, but the 32-bit kernel is the correct one for them to use.
Quotes of the week Posted Jan 22, 2010 13:58 UTC (Fri) by ssam (subscriber, #46587) [Link]
I wonder if he considers atoms/netboooks to be embedded?
the new generation of atoms are 64 bit. so 32bit x86 will be gone soon.
Quotes of the week Posted Jan 28, 2010 3:38 UTC (Thu) by mikachu (guest, #5333) [Link]
FWIW I've been using 1.5G on an old Athlon XP 2600+ without HIGHMEM for over a year with no issues, except an inability to run wine, which I can live with.
Quotes of the week Posted Jan 28, 2010 5:07 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
and the fact that you are not using about 640MB of that 1.5G
David Lang
Quotes of the week Posted Jan 28, 2010 23:21 UTC (Thu) by efexis (guest, #26355) [Link]
Unless you go for a 2G/2G vmsplit option, doesn't that give you use of that memory without resorting to HIMEM? Granted you lose compatibility with some apps, so if he was running something like that, it might leave him with an inability to run WINE, but I got the impression he can do without that ;-)
|
|||||||||||||