On Tue, 1 Aug 2000 ying@almaden.ibm.com wrote:
> What I had found out is that when I ran multiple instances (say
> 3) of this program against 2.4.0-test5, the kernel would eat up
> all the memory it has.
> I suspected that this is a problem that has something to do with
> the fact that the fs buffer cache is consumed much faster than
> can be kflushd/kupdate'd.
> I guess my point is that there seems to be a problem in the way
> that the Linux file system buffer cache uses the memory. Right
> now, it appears to me that there is simply no control on the
> file system buffer cache usage,
There is some control (read balance_dirty() in fs/buffer.c),
but it's not done completely right...
We do write throttling by not allowing more than 40% of the
buffer memory to be dirty, counting cache memory as freeable
memory usable for dirty buffers. This is where we go wrong.
Since we can also use cache memory for other things (most
notably, caching executable code), we'll end up with the
situation that write throttling kicks in so late that we'll
put a high pressure on other, useful, parts of the cache
and indirectly on the RSS of processes and executable code.
The attached patch should alleviate the situation quite a
lot. It guesstimates that 1/3rd of the cache is "freeable"
and old data and takes only that amount into account. The
30% should be about right in heavy write situations because
if we never fill that much cache memory with our writes there
would be no need to do write throttling.
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
--- mm/page_alloc.c.orig Wed Aug 2 10:59:45 2000
+++ mm/page_alloc.c Wed Aug 2 11:01:22 2000
@@ -340,7 +340,7 @@
zone_t *zone;
int i;
- sum = nr_lru_pages;
+ sum = nr_lru_pages / 3;
for (i = 0; i < NUMNODES; i++)
for (zone = NODE_DATA(i)->node_zones; zone <= NODE_DATA(i)->node_zones+ZONE_NORMAL; zone++)
sum += zone->free_pages;
-
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/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:08 EST