Re: 2.2.1 seems to be stable under high load

Andrea Arcangeli (andrea@e-mind.com)
Sat, 30 Jan 1999 02:18:33 +0100 (CET)


On Fri, 29 Jan 1999, Dr. Werner Fink wrote:

> @@ -339,9 +341,14 @@
> read_lock(&tasklist_lock);
> p = init_task.next_task;
> for (; p != &init_task; p = p->next_task) {
> + unsigned long rss = p->mm->rss;
> if (!p->swappable)
> continue;
> - if (p->mm->rss <= 0)
> + if (rss <= 0)
> + continue;
> + if (kswapd && p == current->next_run && rss < limit)
> + continue;
> + if (p == current && rss < limit)
> continue;
> /* Refresh swap_cnt? */
> if (assign)

Consider that you have 8Mbyte of RAM and 121Mbyte of swap (not so unlikely
to happen).

Think to have only one process in the system (think at some embedded-like
application) that needs 13Mbyte of virtual memory to run (even if its
working set is maybe 5Mbyte). At this point you won't be able to run it
beacuse it won't be swapped out from itself and kswap, because it will
always be the current process or kswapd_task->next_run, and his rss will
never be > of 8Mbyte.

To fix the problem I pointed out above, probably we only need to replace:

> + if (kswapd && p == current->next_run && rss < limit)
> + continue;
> + if (p == current && rss < limit)
> continue;

with:

if (!kswapd && p == current && rss < limit)
continue;

This heuristic make sense to me... but there's to say that we just have
the swap cache that should just cope fine with these issues.

Into some day I'll release 2.2.1_arca-1.gz, that has my new VM things in
it (and today I had the time to run for some time a clean 2.2.1 and
noticed that my new code make a real difference). Once it will be ready I
would like if you could try it and see how it scale under heavy VM and CPU
load in your tests ;), I think you should not need your patch to avoid the
current process to go in the swap, we just have the swap cache for this
same reason. Here my iteractive processes are far to go out of swap cache
even if without your patch. But maybe your code will improve thing still
more ? ;)

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/