lkml.org 
[lkml]   [2003]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.22 O_DIRECT memory leak?!?
On Thu, Oct 09, 2003 at 04:37:52PM -0300, Marcelo Tosatti wrote:
>
>
> On Wed, 8 Oct 2003, Magnus Andersson wrote:
>
> > Hello!
> >
> > If I open one file a lot of times using the flag O_DIRECT,
> > memory seems to be be lost and never given back to the system.
> > This is happening on some kernels, see below for which ones I tried.
> >
> > Attached program will produce this behavior, also attached
> > is the output from vmstat while running the program.
>
> Magnus,
>
> That memory will be freed as soon as there's memory pressure so its not a
> memory leak.

Ok. It's not a leak. But it looks like the memory never goes back to the system.
The kernel has killed some processes of mine, thats why I suspect this.

Attached are a program, malloc_mem.
Before running open_odirect, malloc_mem succeeds in allocating 450 000 000 bytes.
After running open_odirect, malloc_mem fails.

It is working on the 2.4.22-aa1 kernel, but not on 2.4.22

The test is run with this amount of memory, and no swap.

Memory: 515752k/524204k available (1593k kernel code, 8064k reserved, 334k data, 264k init, 0k highmem)

/Magnus
foo:~> ./malloc_mem
All ok!
foo:~> ./open_odirect
foo:~> ./malloc_mem
Could not malloc 450000000 bytes
foo:~>
#include <stdio.h>

#define MEM_SIZE 450000000

int main()
{
int i;
char *mem;

mem = (char *)malloc(MEM_SIZE);

if(mem == NULL) {
printf("Could not malloc %d bytes\n", MEM_SIZE);
exit(1);
}

memset(mem, 1, MEM_SIZE);

printf("All ok!\n");
}
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 496804 940 7936 0 0 0 0 101 2 0 0 100 0
0 0 0 496800 940 7940 0 0 0 0 101 6 0 0 100 0
0 0 0 496800 940 7940 0 0 0 0 101 4 0 0 100 0
0 0 0 496800 940 7940 0 0 0 0 101 2 0 0 100 0
0 0 0 496800 940 7940 0 0 0 0 101 2 0 0 100 0
1 0 0 438912 940 7940 0 0 0 0 104 14 71 28 1 0
1 0 0 379896 940 7940 0 0 0 0 101 4 76 24 0 0
1 0 0 320880 940 7940 0 0 0 0 101 4 78 22 0 0
1 0 0 261868 940 7940 0 0 0 0 101 2 74 26 0 0
1 0 0 202848 940 7940 0 0 0 0 101 2 77 23 0 0
1 0 0 143836 940 7940 0 0 0 0 101 2 73 27 0 0
1 0 0 84856 940 7940 0 0 0 0 101 8 76 24 0 0
0 0 0 496716 940 7940 0 0 0 0 105 13 35 17 49 0
0 0 0 496716 940 7940 0 0 0 0 101 2 0 0 100 0
0 0 0 496716 940 7940 0 0 0 0 101 2 0 0 100 0
0 0 0 496716 940 7940 0 0 0 0 107 16 0 0 100 0
0 0 0 496716 940 7940 0 0 0 0 104 11 0 0 100 0
1 0 0 461916 940 7940 0 0 0 128 137 27 0 17 83 0
0 0 0 385028 940 7940 0 0 0 0 103 7 0 50 50 0
0 0 0 385028 940 7940 0 0 0 0 101 2 0 0 100 0
0 0 0 385028 940 7940 0 0 0 0 101 4 0 0 100 0
0 0 0 385028 940 7940 0 0 0 0 107 20 0 0 100 0
0 0 0 385028 940 7940 0 0 0 76 126 22 0 0 100 0
0 0 0 385028 940 7940 0 0 0 0 101 2 0 0 100 0
0 0 0 385028 940 7940 0 0 0 0 101 2 0 0 100 0
0 0 0 385024 940 7944 0 0 0 0 101 2 0 0 100 0
0 0 0 385024 940 7944 0 0 0 0 101 4 0 0 100 0
0 0 0 385024 940 7944 0 0 0 0 101 4 0 0 100 0
\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.322 / U:1.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site