> On Tue, 13 Jun 2000, Rik van Riel wrote:
>
> >You're forgetting one thing. When current->thrashing_mem is set
> >for a number of applications, and kswapd is woken up, only one
> >of these applications will get the chance to have its thrashing_mem
> >flag reset to 0.
> >
> >Here's why. Kswapd will *stop* freeing memory when free_pages
> >reaches freepages.high, meaning that only *one* process, depending
>
> This is not exactly true, kswapd will stop between frepages.high and
> freepages.high+32pages.
2.2.15, mm/vmscan.c, kswapd thread:
while (1) {
interruptible_sleep_on(&kswapd_wait);
while (nr_free_pages < freepages.high)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{
if (do_try_to_free_pages(GFP_KSWAPD))
{
if (tsk->need_resched)
schedule();
continue;
}
tsk->state = TASK_INTERRUPTIBLE;
schedule_timeout(10*HZ);
}
}
What i'm missing here ?
>
> >on chance, will have its thrashing_mem flag reset.
>
> I see your point, however the heuristic was not working bad in real life.
It was, here, with several people on desktop workloads.
> >Now we come to the chance part. Suppose you have one "active
> >allocator", doing 30 allocations per second, and 3 less active
> >programs, which each do 3 allocations per second. The chance that
> >the memory "hog" will have its thrashing_mem flag reset is 75%,
> >while at the same time there's quite a chance that the other
> >processes will not have their flag reset.
>
> The hogs will keep the memory between min and low and all the non hogs
> will be allowed to allocate without blocking inside the min and low
> watermarks.
> That's the basic point. In the meantime kswapd will try to
> port the nr_free_pages over high and if that will happen it means there's
> not memory pressure and the tasks can exit the hog mode.
> I see if an innocent task is classified as hog it won't easily exit but as
> far as it' s not classified as hog it will allocate without blocking.
But unfortunately innocent tasks can be classified as hogs with the
2.2.15 thrasing heuristic.
> >> The cure for the probably you mentioned is very away from page_alloc.c,
> >> I think this was the cure:
> >>
> >>
> >> /* Then, try to page stuff out.. */
> >> + swapcount = flushcount;
> >> while (swap_out(priority, gfp_mask)) {
> >> - if (!--count)
> >> - goto done;
> >> + if (!--swapcount)
> >> + break;
> >> }
> >
> >This has nothing at all to do with the thrashing heuristic.
>
> the thrashing heuristic can't cause instabilities (it can only affect the
> performance of the system), so the above part is the one that is going to
> be related to the instabilties of the mmap002 test.
mmap002 on 2.2.15 gets killed. mmap002 on 2.2.15 + 2.2.16's
thrasing heuristic runs fine. Try it.
-
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/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:32 EST