> 2) In pre-5, under heavy load, free memory is hovering around
> freepages.min instead of being somewhere between freepages.low &
> freepages.max. This could make trouble for bursts of atomic
> allocations (networking!).
Agreed and I just fixed that with my updates to the memory trashing
heuristic (see also the second patch in one of my last emails).
A new minimal patch against 2.2.0-pre5 is this:
Index: page_alloc.c
===================================================================
RCS file: /var/cvs/linux/mm/page_alloc.c,v
retrieving revision 1.1.1.6
diff -u -2 -r1.1.1.6 page_alloc.c
--- page_alloc.c 1999/01/07 11:21:35 1.1.1.6
+++ linux/mm/page_alloc.c 1999/01/07 19:34:58
@@ -4,4 +4,5 @@
* Copyright (C) 1991, 1992, 1993, 1994 Linus Torvalds
* Swap reorganised 29.12.95, Stephen Tweedie
+ * trashing_memory heuristic. Copyright (C) 1999 Andrea Arcangeli
*/
@@ -259,7 +260,4 @@
* to free things up until things are better.
*
- * Normally we shouldn't ever have to do this, with
- * kswapd doing this in the background.
- *
* Most notably, this puts most of the onus of
* freeing up memory on the processes that _use_
@@ -269,8 +267,9 @@
if (!current->trashing_memory)
goto ok_to_allocate;
- if (nr_free_pages > freepages.low) {
+ if (nr_free_pages > freepages.high) {
current->trashing_memory = 0;
goto ok_to_allocate;
- }
+ } else if (nr_free_pages > freepages.low)
+ goto ok_to_allocate;
}
/*
The problem is that I don't know if it's going to hurt performances... If
somebody would try it out would be helpful... I don't think it can
hurt but...
Andrea Arcangeli
-
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/