Pascal Hambourg wrote: > Bob Proulx a écrit : > > A 64-bit kernel won't have much advantage for a 32-bit userspace. > > Quote for the kernel source : > Linux can use up to 64 Gigabytes of physical memory on x86 systems. > However, the address space of 32-bit x86 processors is only 4 > Gigabytes large. That means that, if you have a large amount of > physical memory, not all of it can be "permanently mapped" by the > kernel. The physical memory that's not permanently mapped is called > "high memory". > > If the address range available to the kernel is less than the > physical memory installed, the remaining memory will be available > as "high memory". Accessing high memory is a little more costly > than low memory, as it needs to be mapped into the kernel first. > > By default, a 32-bit kernel splits the 4 GiB address space in 1 GiB for > low memory and 3 GiB for user address space. So all physical memory > above 1 GiB (high memory) cannot be permanently mapped, and each user > process has a usable virtual address space of 3 GiB. Yes. As stated accessing this extra memory space will require remapping the page registers. Basically it causes a page fault and the kernel page fault handler will remap the pages to allow access to the newly accessed pages of memory. This causes the access to be slower because it must trigger a page fault first and the kernel must remap the pages. But that won't happen all of the time. Usually you would only have one program that is using a large amount of memory. If that is a 32-bit program then it is limited to 3G of memory. There is a 3G limit per process for 32-bit programs. Therefore no 32-bit program is going to use more than 3G. Therefore, say, in an 8G ram system no single program can thrash the 8G system memory. It may cause other programs pages to be remapped out but after having done so then the large 3G program would usually stay mapped. Of course if you were running two or more large 3G programs on an 8G ram system with a 32-bit PAE kernel and both of them were running then each of them would be page faulting and remapping out the other's pages. But all of the pages stay in ram. This isn't a classic thrash of VM to swap. No disk is involved. All of the pages are in ram. It is just the kernel page map tables that get remapped. So pretty fast. But still a page fault trap and handle when it needs to be remapped. So not completely without cost. Every so often instead of a fast ram access it causes a page trap and handle to fixup the access. Performance is easy to guess at but hard to guess correctly. Things we think will have a high performance change tend not to be so large. Things we think won't make a difference tends to make a bigger difference. This is why objective benchmarks are really the only way to measure it. And benchmarks are small little snapshot views which is why we have so many different ways to benchmark. Also a 32-bit system can install a 64-bit kernel. But all of the application userland would still be 32-bit. In order to really have advantage the kernel and the userland both would need to be converted to 64-bit. If someone had already installed a 32-bit system then installing the 64-bit kernel is easy and trouble free. Go for it. But I don't think it is necessary to reinstall the system to get a 64-bit userland just for having it. However not having a 64-bit userland means the benefits of the 64-bit kernel are limited. > IIRC, a 64-bit kernel gets rid of the memory split, which has two > advantages : > - all physical memory is mapped permanently, no more low/high memory > above 1 GiB Yes! Exactly. Since the 64-bit kernel can directly access all of the ram without secondary page registers it doesn't ever need the page fault trap handle to remap the PAE page registers. Instead it simply uses a flat address space for all memory. The performance penalty of the 32-bit PAE kernel when it needs to remap pages is gone. It was only a small penalty and only triggered when running multiple processes however. This performance difference is not typically noticeable by a desktop user. Scientific and engineering users running compute tasks in a compute farm are the ones who will mostly notice the difference. > - 32-bit user processes have a usable virtual address space of 4 GiB > instead of 3 GiB. > > So I guess that memory intensive 32-bit applications could take > advantage of a 64-bit kernel. Yes. We used to do that all of the time. The actual number number is just short of 4G. A 32-bit test program that malloc()'s 1M of memory in a loop will be able to malloc() 3056M of memory on a 32-bit kernel but 3803M of memory on a 64-bit kernel. The 64-bit kernel allows the 32-bit program to have 747M more space. Again desktop users will be unlikely to notice this capability difference. Scientific and engineering users often need to run large memory programs that have grown above 3G of memory space required. Being able to get a little bit extra memory for their program may allow them to run their 32-bit program on a 64-bit kernel up to 3.8G of memory when it fails to run on a 32-bit due to running out of memory at 3G. (I have been there many times running engineering CAD/EDA software.) However now that 64-bit systems with lots of memory are common the need to squeeze another 747M out of a 32-bit program is not needed. These days everything worthwhile is available in 64-bit architectures. Whereas back in the year 2000 or so few systems were 64-bits. Back then we needed to squeeze running proprietary CAD/EDA programs without source through a 3.5G memory image. These days we would just use a 64-bit version of the program and run it on a machine with 64G of ram and keep it simple by brute force instead. > > Is your web browser exceeding 3G of ram image? > > Is this possible with a 32-bit kernel ? Sorry. I was being funny there. I was somewhat joking about browsers and the web being memory pigs. I think today the web browser is arguably the primary desktop application. It sits between 1G and 2G of memory on my desktop. It sometimes runs between 2G and 3G! Wow. Whenever I want to free up memory I always close down all of my web browsers first and that is usually sufficient. I was partially making fun of the web browser for being such a memory pig. I was partially making the point that it isn't necessary to migrate to a 64-bit system because the browser isn't yet needing to go beyond 3G. But one day quite soon I expect that web browsers will no longer fit usefully in a 32-bit memory space. But for now if someone has already installed a 32-bit system then I wouldn't say it is necessary for them to reinstall a 64-bit system. At least not yet. Bob
Attachment:
signature.asc
Description: Digital signature