|
From: Nicholas N. <nj...@ca...> - 2004-08-05 11:17:37
|
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 |