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.
> On Tue, 13 Jun 2000, Andrea Arcangeli wrote:
> > On Mon, 12 Jun 2000, Marcelo Tosatti wrote:
> >
> > >It does fix stability problems, most notably VM changes.
> >
> > Could you tell me about a VM bug in 2.2.15 that is been fixed in 2.2.16?
For me the 2.2 and 2.3 allocator seem quite broken anyway. If the disk is
too slow to do swap-outs, interrupts are coming and eating all atomic
memory, and somebody calls GFP_KERNEL or GFP_USER allocation - it could
return NULL even if there is plenty of swap space.
This could not happen in 2.0 - it had infinite loop that called
try_to_free_pages until there was enough memory or until it returned 0. I
would like to know why this was dropped in 2.2.
Mikulas
-
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:30 EST