kopia lustrzana https://gitlab.com/sane-project/website
157 wiersze
6.2 KiB
HTML
157 wiersze
6.2 KiB
HTML
<!-- received="Tue Mar 17 09:12:19 1998 PST" -->
|
|
<!-- sent="Tue, 17 Mar 1998 11:11:36 -0600" -->
|
|
<!-- name="Leigh Orf" -->
|
|
<!-- email="orf@mailbag.com" -->
|
|
<!-- subject="Re: memory leak: Microtek E6 / aha152x / RH 5.0" -->
|
|
<!-- id="199803171711.LAA01068@msn-1-48.x2.binc.net" -->
|
|
<!-- inreplyto="memory leak: Microtek E6 / aha152x / RH 5.0" -->
|
|
<title>sane-devel: Re: memory leak: Microtek E6 / aha152x / RH 5.0</title>
|
|
<h1>Re: memory leak: Microtek E6 / aha152x / RH 5.0</h1>
|
|
<b>Leigh Orf</b> (<a href="mailto:orf@mailbag.com"><i>orf@mailbag.com</i></a>)<br>
|
|
<i>Tue, 17 Mar 1998 11:11:36 -0600</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#114">[ date ]</a><a href="index.html#114">[ thread ]</a><a href="subject.html#114">[ subject ]</a><a href="author.html#114">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0115.html">Peter JD Hall: "Re: Adaptec AVA-1502AE vs. aha152x"</a>
|
|
<li> <b>Previous message:</b> <a href="0113.html">Christoph Doerbeck: "Comments on my presentation outline"</a>
|
|
<li> <b>Maybe in reply to:</b> <a href="0106.html">Leigh Orf: "memory leak: Microtek E6 / aha152x / RH 5.0"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
OK, I'm following up my own post about this memory leak. I applied<br>
|
|
the unofficial memleak-deluxe patch to the 2.0.33 kernel. The memleak<br>
|
|
patch writes a file called /proc/memleak which can be analyzed by a few<br>
|
|
enclosed scripts.<br>
|
|
<p>
|
|
<p>
|
|
the first number the 'allocation count', the number of memory objects<br>
|
|
allocated in a certain FILE:LINE. If some allocation point shows a<br>
|
|
constantly increasing allocation count, it's probably a memory leak.<br>
|
|
<p>
|
|
The FAQ goes on to say:<br>
|
|
<p>
|
|
NOTE: the VM subsystems usually have very fluctuating allocation counts,<br>
|
|
think twice before calling them a memory leak.<br>
|
|
<p>
|
|
buffer.c is part of that code, but since it's growing consistently (not<br>
|
|
fluctuating), and has the largest magnitude, I'm pretty sure that's<br>
|
|
where the trouble is. I ran the dosum script six times, once after<br>
|
|
each scan, concatenated the output to a file, and it appears that the<br>
|
|
memory being allocated at lines 1004 and 1359 in buffer.c are not being<br>
|
|
deallocated (esp. 1004 as far as magnitude of the leak, I'm not sure<br>
|
|
about 1359). This increase in buffer-cache matches my observations of<br>
|
|
xsysinfo output. If I would have run it about 20 more times I would have<br>
|
|
been out of memory altogether.<br>
|
|
<p>
|
|
home[1006]:/home/orf/memleak-deluxe% grep buffer out | grep 1004<br>
|
|
22337 buffer.c:1004 <br>
|
|
25750 buffer.c:1004 <br>
|
|
29923 buffer.c:1004 <br>
|
|
33732 buffer.c:1004 <br>
|
|
37766 buffer.c:1004 <br>
|
|
42143 buffer.c:1004 <br>
|
|
<p>
|
|
home[1007]:/home/orf/memleak-deluxe% grep buffer out | grep 1359<br>
|
|
<p>
|
|
5590 buffer.c:1359 <br>
|
|
6448 buffer.c:1359 <br>
|
|
7476 buffer.c:1359 <br>
|
|
8443 buffer.c:1359 <br>
|
|
9440 buffer.c:1359 <br>
|
|
10542 buffer.c:1359 <br>
|
|
<p>
|
|
Here are code snippets where these allocations occur:<br>
|
|
<p>
|
|
<p>
|
|
986 static void get_more_buffer_heads(void)<br>
|
|
987 {<br>
|
|
988 struct wait_queue wait = { current, NULL };<br>
|
|
989 struct buffer_head * bh;<br>
|
|
990<br>
|
|
991 while (!unused_list) {<br>
|
|
992 /*<br>
|
|
993 * This is critical. We can't swap out pages to get<br>
|
|
994 * more buffer heads, because the swap-out may need<br>
|
|
995 * more buffer-heads itself. Thus GFP_ATOMIC.<br>
|
|
996 *<br>
|
|
997 * This is no longer true, it is GFP_BUFFER again, the<br>
|
|
998 * swapping code now knows not to perform I/O when that<br>
|
|
999 * GFP level is specified... -DaveM<br>
|
|
1000 */<br>
|
|
1001 /* we now use kmalloc() here instead of gfp as we want<br>
|
|
1002 to be able to easily release buffer heads - they<br>
|
|
1003 took up quite a bit of memory (tridge) */<br>
|
|
***1004 bh = (struct buffer_head *) kmalloc(sizeof(*bh),GFP_BUFFER);<br>
|
|
1005 if (bh) {<br>
|
|
1006 put_unused_buffer_head(bh);<br>
|
|
1007 nr_buffer_heads++;<br>
|
|
1008 return;<br>
|
|
1009 }<br>
|
|
1010<br>
|
|
1011 /*<br>
|
|
1012 * Uhhuh. We're _really_ low on memory. Now we just<br>
|
|
1013 * wait for old buffer heads to become free due to<br>
|
|
1014 * finishing IO..<br>
|
|
1015 */<br>
|
|
1016 run_task_queue(&tq_disk);<br>
|
|
.<br>
|
|
<p>
|
|
.<br>
|
|
<p>
|
|
.<br>
|
|
<p>
|
|
.<br>
|
|
<p>
|
|
<p>
|
|
1345 static int grow_buffers(int pri, int size)<br>
|
|
1346 {<br>
|
|
1347 unsigned long page;<br>
|
|
1348 struct buffer_head *bh, *tmp;<br>
|
|
1349 struct buffer_head * insert_point;<br>
|
|
1350 int isize;<br>
|
|
1351<br>
|
|
1352 if ((size & 511) || (size > PAGE_SIZE)) {<br>
|
|
1353 printk("VFS: grow_buffers: size = %d\n",size);<br>
|
|
1354 return 0;<br>
|
|
1355 }<br>
|
|
1356<br>
|
|
1357 isize = BUFSIZE_INDEX(size);<br>
|
|
1358<br>
|
|
***1359 if (!(page = __get_free_page(pri)))<br>
|
|
1360 return 0;<br>
|
|
1361 bh = create_buffers(page, size);<br>
|
|
1362 if (!bh) {<br>
|
|
1363 free_page(page);<br>
|
|
1364 return 0;<br>
|
|
1365 }<br>
|
|
1366<br>
|
|
1367 insert_point = free_list[isize];<br>
|
|
<p>
|
|
Anyhow, I am not a kernel hacker and could be barking up the wrong<br>
|
|
tree... let me know if any of you have ideas on this, or if you can<br>
|
|
point me in the right direction. I figure I'm not the only one with this<br>
|
|
problem.<br>
|
|
<p>
|
|
Leigh Orf<br>
|
|
<p>
|
|
<p>
|
|
<p>
|
|
<p>
|
|
<pre>
|
|
--
|
|
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
|
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
|
</pre>
|
|
<!-- body="end" -->
|
|
<p>
|
|
<ul>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0115.html">Peter JD Hall: "Re: Adaptec AVA-1502AE vs. aha152x"</a>
|
|
<li> <b>Previous message:</b> <a href="0113.html">Christoph Doerbeck: "Comments on my presentation outline"</a>
|
|
<li> <b>Maybe in reply to:</b> <a href="0106.html">Leigh Orf: "memory leak: Microtek E6 / aha152x / RH 5.0"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|