On Wed, 14 Jun 2000, Mikulas Patocka 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:
> >
> > 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 won't. Go through the code.
> And even if it did, it wouldn't cause trouble.
I misread the code, sorry. Anyway, imagine a situation where you have
one memory hog, doing lots of allocations (say 10/s), and, lets say,
2 other processes doing less allocations (say 1/s) and all them have
trashing_mem == 1. When kswapd reaches freepages.high free pages it
will sleep. When nr_free_pages == freepages.high, one process will have
the chance to clear the trashing_mem flag. Since the big hog is doing
much more allocation per second than the others processes, it will have
more chance to get the trashing_mem flag cleared, then allocate one
page, decrementing nr_free_pages making the other processes lose the
chance to clear the trashing_mem flag. This is quite unfair, IMO.
Please correct me if i'm wrong.
-
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