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.
> 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.
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;
}
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