Messages in this thread | | | Date | Sat, 30 Jan 1999 02:18:33 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 2.2.1 seems to be stable under high load |
| |
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/
| |