On Sat, Aug 27, 2005 at 23:19:25 +0300, Hayim Shaul wrote:
> I have a computer with 4GB with FedoraCore3 installed, and wrote this
> program that allocates a >2G array:
What is so special on 2G? It is special for files (where file offsets are
signed, so you get only 31 bits), but it shouldn't be special at all for
memory. I'd expect you get exactly the same result if you try to allocate
(1 << 31) - 1000 instead of (1 << 31) + 1000.
> int main(int,char**) {
> unsigned int size = (unsigned int)2 * 1024 *1024 *1024 + 1000;
> char *p;
>
> p = malloc(size);
> if (p != NULL)
> printf("OK\n");
> else
> printf("Bad\n");
> }
>
> Using the kernel supplied with FC the buffer is allocated. When I use a
> kernel I compile malloc returns NULL.
> I am aware of the high-mem support and I tried it set to 4G and 64G.
> Furthermore, when I compile a kernel with the config file given by FC
> (linux-2.6.5-1.358/configs/kernel-2.6.5-i* ) it
> doesn't work (although the kernel should be configured the same).
No, this has nothing at all to do with highmem. The Fedora kernel is so
called '4GB' kernel, which uses separate page tables for kernel to give
userspace 4GB of address space, instead of 3GB in normal kernel. At the
expense of being slower because _every_ kernel entry/exit means tlb flush.
> Obviously this has something to do with the way I build the kernel,
> since when I use the kernel supplied with FC3 it works well.
No, it does not. It does have something to do with patches applied on the FC3
kernel -- their kernel is VERY different from official kernel from
kernel.org.
> I also tried to copy a good kernel I compiled on another machine (together
> with its modules) and this one doesn't work as well, although on the
> original machine it worked.
>
> Another strange thing:
> Using ldd on the "bad" machine I get:
> [root@host1 root]# ldd test_hi_mem
> linux-gate.so.1 => (0x00280000)
> libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4e056000)
> libm.so.6 => /lib/tls/libm.so.6 (0x4d316000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4deb8000)
> libc.so.6 => /lib/tls/libc.so.6 (0x4d1f3000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4d1da000)
>
> while on the "good" machine I get:
> [root@host2 root]# ldd test_high_mem
> linux-gate.so.1 => (0xffffe000)
> libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x072d7000)
> libm.so.6 => /lib/tls/libm.so.6 (0x0079c000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x005f3000)
> libc.so.6 => /lib/tls/libc.so.6 (0x00679000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00660000)
Hm, this difference is really in the dynamic loader (ld-linux.so). AFAIK
kernel does not decide where to load stuff.
> This suggests that the "bad" machine puts the libraries in the middle of
> the address space. But then I do not understand how any kernel can
> allocate 2G.
With the Fedora kernel, the userspace has 4GB address space instead of 3GB,
so it manages to fit the block in.
--
Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
