|
From: pkr <pan...@ya...> - 2004-08-05 12:10:45
|
Ok, 2 pieces of info. 1. As Nick guessed earlier, the kernel is configured for 4GB and 2GBuser/2GB kernel . from make menuconfig of our kernel. ======================================== <*> /dev/cpu/*/cpuid - CPU information support (4GB) High Memory Support [ ] HIGHMEM I/O support (NEW) (2GB) User address space size [ ] Math emulation [*] MTRR (Memory Type Range Register) support ======================================= 2. output of cat /proc/self/maps Linux(debug)# cat /proc/self/ cmdline environ fd mem root statcpu statpages cwd exe maps mounts stat statm status Linux(debug)# cat /proc/self/maps 08048000-0804b000 r-xp 00000000 00:000007 30 /bin/cat 0804b000-0804c000 rw-p 00002000 00:000007 30 /bin/cat 0804c000-0804d000 rwxp 00000000 00:000000 0 2aaab000-2aac0000 r-xp 00000000 00:000007 828 /lib/ld-2.3.2.so 2aac0000-2aac1000 rw-p 00014000 00:000007 828 /lib/ld-2.3.2.so 2aac1000-2aac2000 rw-p 00000000 00:000000 0 2aac4000-2abfb000 r-xp 00000000 00:000007 835 /lib/libc-2.3.2.so 2abfb000-2abff000 rw-p 00136000 00:000007 835 /lib/libc-2.3.2.so 2abff000-2ac02000 rw-p 00000000 00:000000 0 7fffe000-80000000 rwxp fffff000 00:000000 0 Let me know if there could be a fix from valgrind. Thanks, Pankaj Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, Tom Hughes wrote: > >>> My system only has 1 GB. But something similar to what you suggest is >>> not ruled out. (As we have a memory mapped IPC system (proprietory) >>> which reserves some huge amout of memory during kernel init) >> >> >> It isn't a question of how much physical memory you have, it's how the >> address space is split between the user space and the kernel space. >> >> The normal split is 3Gb to user space and 1Gb to kernel although some >> systems now give the whole 4Gb to user space. You can also build the >> kernel to give 1Gb to the user and 3Gb to the kernel or 2Gb to each >> which is what it looks like your system is doing. >> >> Like you say, this is probably related to your IPC system needing >> extra kernel address space. > > > Yes, sounds like it. > > I'd be interested to see what /proc/self/maps looks like for a typical > process. Pankaj, can you run "vim /proc/self/maps" or something > similar, and post the results? Thanks. > > ---- > > Ultimately, I think the full virtualisation of the address space > introduced in 2.1.1 has enough problems in tricky cases like this that > we should be prepared to consider a fall-back scheme that operates more > like 2.0.0, whereby valgrind's memory and the client's memory are mixed > up much more. Eg. if you specified --pointer-check=no. This does have > disadvantages -- eg. a buggy client can trash Valgrind's memory -- but > it seems like there's a small fraction of programs for which the current > approach is just too rigid. This could be difficult, though. > > (Nb: "full virtualisation" is not an accurate name, we haven't > virtualised the address space, just partioned it.) > > N > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com |