> Michael L. Galbraith wrote:
> > Could you take the following and modify it to your needs and try it?
> > Run your system for a bit, do a Bonnie, run a bit more before starting
> > the test. Bonnie on a freshly booted system doesn't seem to kick out
> > as much from buffers as when run after tinkering a bit.
> >
> > I'm not seeing any growth there, so that's a good verification that
> > memleak is seeing something real. (since it agrees with SysRq-M)
>
> ok, I was finally able to try out things again. (Darn military)
>
> I've included a tar.gz with all the dosum,delta,and Mem-Info's.
> filemap.c:316 sticks out again. (I have no idea what this portion of code
> does, so I would be happy if you can explain it sometime)
>
Ok Jeff, it looks to me like we have this thing about as documented as
we're going to get it, so I'm extracting the pertinent data from your
last two runs and posting it for guru examination.
Could you please add your configuration to this with a blurb concerning
what you've done to confirm that the es1370 driver triggers this to refresh
peoples memories?
wrt explanation.. sorry, my understanding of buffercache and such is just
plain too foggy to even attempt that :)
I was hoping to see a steady increase at some allocation point, but
unfortunately that isn't happening. You do have memory piling up at a
point where it doesn't on my machine though, so I'll have to presume that
this is the black hole.
-Mike
*************************************************************************
NOTE: in order for memleak to see this leak, I had to totally disable
logging in buffer.c. The memleak allocation/deallocation mapping for
__get_free_pages() takes place inside of the page allocator under it's
spinlock, so it _should_ show up regardless. It is a complete mystery
to me as to why it does not if buffer.c is logged.
*************************************************************************
This is the delta info from your last small confirmation test showing
every allocation point with a DELTA != 0.. my system does not show any
growth in filemap.c running same test.
dcache.c:505: 179 8 3 1 1 1 1 1 1 1 1 1 -18 DELTA: 2
dst.c:87: 5 0 0 0 0 0 0 0 0 0 0 0 -2 DELTA: -2
filemap.c:1005: 12 0 0 0 0 0 0 0 0 0 0 -1 -6 DELTA: -7
filemap.c:1042: 66 0 0 0 0 0 0 0 0 0 0 0 -14 DELTA: -14
filemap.c:316: 535 0 0 0 -2 -3 -4 -2 -1 0 -3 -2 66 DELTA: 49
filemap.c:739: 52 0 0 0 0 5 -4 -1 1 0 0 1 -5 DELTA: -3
fork.c:414: 10 0 0 0 0 0 0 0 0 0 0 0 1 DELTA: 1
memory.c:645: 48 0 0 0 0 5 -1 0 0 0 1 1 -25 DELTA: -19
memory.c:865: 59 0 0 0 1 1 4 5 1 4 4 2 -32 DELTA: -10
namei.c:92: 38 0 0 0 0 0 3 0 2 1 1 -2 -7 DELTA: -2
select.c:139: 11 0 0 0 0 0 -1 0 0 0 0 0 -1 DELTA: -2
swap_state.c:269: 21 0 0 0 0 0 0 -1 0 0 0 0 15 DELTA: 14
allocation map diff (before/after) from your previous much larger run.
-5 filemap.c:1005
-26 filemap.c:1042
-276 filemap.c:316
-10 filemap.c:739
-1 fork.c:119
+1 filemap.c:1005
+9 filemap.c:1042
+405 filemap.c:316
+50 filemap.c:739
meminfo before/after from the same run. Here, I noticed that you
had a dma timeout. Does this happen a lot?.. it might be a clue.
<4>Mem-info:
<4>Free pages: 23136kB
<4> ( Free: 5784 (64 128 192)
<4>64*4kB 270*8kB 225*16kB 125*32kB 87*64kB 59*128kB = 23136kB)
<4>Swap cache: add 214/214, delete 210/210, find 0/0
<4>Free swap: 26984kB
<4>7281 pages of RAM
<4>398 reserved pages
<4>84 pages shared
<4>4 pages swap cached
<4>28 pages in page table cache
<4>Buffer memory: 1692kB
<4>Buffer heads: 1720
<4>Buffer blocks: 1692
<4> CLEAN: 1568 buffers, 75 used (last=75), 0 locked, 0 protected, 0 dirty
<4> LOCKED: 5 buffers, 5 used (last=5), 0 locked, 0 protected, 0 dirty
<4> DIRTY: 62 buffers, 13 used (last=21), 0 locked, 0 protected, 62 dirty
<4>Networking buffers in use : 0
<4>Total network buffer allocations : 99
<4>Total failed network buffer allocs : 0
<4>IP fragment buffer size : 0
<7>es1370: dma timed out??
<4>Mem-info:
<4>Free pages: 14408kB
<4> ( Free: 3602 (64 128 192)
<4>100*4kB 307*8kB 214*16kB 150*32kB 38*64kB 7*128kB = 14408kB)
<4>Swap cache: add 600/600, delete 594/594, find 0/0
<4>Free swap: 26988kB
<4>7281 pages of RAM
<4>398 reserved pages
<4>92 pages shared
<4>6 pages swap cached
<4>28 pages in page table cache
<4>Buffer memory: 1592kB
<4>Buffer heads: 1620
<4>Buffer blocks: 1592
<4> CLEAN: 1471 buffers, 75 used (last=75), 0 locked, 0 protected, 0 dirty
<4> LOCKED: 5 buffers, 5 used (last=5), 0 locked, 0 protected, 0 dirty
<4> DIRTY: 65 buffers, 13 used (last=21), 0 locked, 0 protected, 65 dirty
<4>Networking buffers in use : 0
<4>Total network buffer allocations : 99
<4>Total failed network buffer allocs : 0
<4>IP fragment buffer size : 0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/