From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Dugger Date: Tue, 05 Mar 2002 17:46:29 +0000 Subject: Re: [Linux-ia64] Fix for for memory leak in IA32 mmap Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-ia64@vger.kernel.org David- Yep, it was a virtual memory leak. Intel came up with a Fortran program that was allocating and freeing lots of anonymous `mmap's. It was really nasty because it wasn't even the same request all the time, it had something like 3 different odd size requests that it was `mmap'ing and `munmap'ing, all in a loop and eventually it ran out of VM. I like the idea of keeping a bitmap. I still have to keep a list, it'll actually be a bigger list since I'll have to keep track of fixed requests also, but that should handle ALL cases (even the case where a program makes an odd sized non-fixed `mmap' followed by a fixed `mmap' into the middle of the last page). Give me a few days and I'll see if I can't come up with something. On Tue, Mar 05, 2002 at 09:34:37AM -0800, David Mosberger wrote: > >>>>> On Tue, 5 Mar 2002 08:13:01 -0700, Don Dugger said: > > Don> David- Here is a patch against `linux-2.4.17-ia64-011226.diff' > Don> that fixes a memory leak with the IA32 `mmap'/`munmap' calls. > Don> The problem occurs when a non-fixed `mmap' allocates a range > Don> that ends in the middle of a page. > > Nasty. You're talking about a _virtual_ address space leak, right? Do > you know the exact sequence of events that causes application failure? > > Don> To handle problems with > Don> fixed requests the `munmap' call rounds down the the area > Don> freed, causing the memory leak. The only solution I can think > Don> of to deal with this is to create a list of the allocated > Don> starting addresses for all non-fixed `mmap' requests. `munmap' > Don> then checks this list and, if it finds a match, rounds the > Don> request size up rather than down. > > It seems to me what we really want to do is keep track of partially > mapped pages. I think we'd need a bitmask showing which ia32 pages > have been mapped in an ia64 page. Say, a 16KB page whose first 4KB > have been mapped would be represented as: > > ia32 page: > 0 1 2 3 > > 1 0 0 0 > > now, if someone maps the 3rd 4KB page, you'd get: > > ia32 page: > 0 1 2 3 > > 1 0 1 0 > > and so on. The underlying ia64 page would then have to be freed > whenever the bitmask becomes empty. > > --david -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale n0ano@n0ano.com Ph: 303/449-0877