Messages in this thread | | | Date | Mon, 1 Feb 1999 13:02:42 +0100 | From | "Dr. Werner Fink" <> | Subject | Re: 2.2.1 seems to be stable under high load |
| |
> > @@ -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/
| |