RE: your mail

Bloch, Jack
2004-02-13T19:23:52Z

By the way shouldn't a munmap call really free the memory. I have an strace
showing that the process calls munmap a lot but I do not seeany gaps in the
map file

Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com

-----Original Message-----
From: Bloch, Jack
Sent: Friday, February 13, 2004 2:14 PM
To: 'Maciej Zenczykowski'
Cc: linux-kernel@vger.kernel.org
Subject: RE: your mail

Yes, your assumtion about the 1GB is correct.

Jack Bloch
Siemens ICN
phone (561) 923-6550
e-mail jack.bloch@icn.siemens.com

-----Original Message-----
From: Maciej Zenczykowski [mailto:maze@cela.pl]
Sent: Friday, February 13, 2004 1:11 PM
To: Bloch, Jack
Cc: linux-kernel@vger.kernel.org
Subject: Re: your mail

The deleted marks in question mean that the file in question has been
unlinked (rm'ed), however it is still being used and the inode in question
still exists. This memory is in use and thus validly takes up mapping
space. You'd need to unmap inorder to free that memory. Deleting a file
does not delete that file until _all_ processes close and unmap any
references to it. What's more worrying is the large area of unmapped
memory below 1GB (0x40000000), wonder why it doesn't get allocated? But I
think the answer is that the standard allocator only searches 1GB..3GB for
free areas...

Cheers,
MaZe.

On Fri, 13 Feb 2004, Bloch, Jack wrote:

> I am running a 2.4.19 Kernel and have a problem where a process is using
the
> up to the 0xC0000000 of space. It is no longer possible for this process
to
> get any more memory vi mmap or via shmget. However, when I dump the
> /procs/#/maps file, I see large chunks of memory deleted. i.e this should
be
> freely available to be used by the next call. I do not see these addresses
> get re-used. The maps file is attached.
>
> <<9369>>
>
> Jack Bloch
> Siemens ICN
> phone (561) 923-6550
> e-mail jack.bloch@icn.siemens.com
>
>