On Wed, 14 Jun 2000, Andrea Arcangeli wrote:
> On Tue, 13 Jun 2000, Marcelo Tosatti wrote:
>
> >Running memtest on 2.2.15 caused the kernel to kill the
> >mmap02 program _fast_. 2.2.16 is able to run all memtest programs
> >without problems. Looking at 2.2.15's page_alloc.c:
>
> So it was the swap_out that was causing the system to think some
> memory was released while it wasn't. I never had problems but I
> guess the no-swapout patch could have hided the problem very
> well and that's why I could have not noticed that.
Dozens of people _have_ noticed and sent in bugreports and horror
stories about 2.2.15 VM...
> > if (nr_free_pages >= freepages.high)
> > {
> > /* share RO cachelines in fast path */
> > if (current->trashing_mem)
> > current->trashing_mem = 0;
> > goto ok_to_allocate;
> > }
> > else
> > {
> > if (nr_free_pages < freepages.low)
> > wake_up_interruptible(&kswapd_wait);
> > if (nr_free_pages > freepages.min && !current->trashing_mem)
> > goto ok_to_allocate;
> > }
> >
> > current->trashing_mem = 1;
> > current->flags |= PF_MEMALLOC;
> > freed = try_to_free_pages(gfp_mask);
> > current->flags &= ~PF_MEMALLOC;
> >
> >As i see here, a process which has trashing_mem == 1 will call
> >do_try_to_free_pages() even if nr_free_pages == freepages.high.
> >Is that a correct behaviour?
>
> It's definitely correct, that was a _feature_ that is been
> dropped by mistake IMHO.
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
on chance, will have its thrashing_mem flag reset.
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.
In effect, this scheme is punishing the rest of the system to make
the memory hog run faster. I don't think that was what is was
intended to do...
> 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.
regards,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/
- 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