Re: 2.2.1 seems to be stable under high load

Dr. Werner Fink (werner@suse.de)
Mon, 1 Feb 1999 13:02:42 +0100

> > @@ -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.

Yep, that's clear ... nevertheless it should be possible to avoid such
cases by adding smarter calculations for the `limit' than mine :-)

>
> 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.

kswapd isn't swappable therefore `p == current && rss < limit' would work.
My small patch points out that avoiding the page request calling swap_in()
will increase performance even if swap cache avoids I/O from disk.
This was what page aging was good for.

Werner

-
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/