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.
>on chance, will have its thrashing_mem flag reset.
I see your point, however the heuristic was not working bad in real life.
>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.
>> 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.
Andrea
-
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:29 EST