buggy GFP_KERNEL allocators

[Rik van Riel]

On Thu, 27 Jan 2000, Andrea Arcangeli wrote:

> I think the real fix for 2.2.15pre is this:
> 
> --- 2.2.15pre4/mm/page_alloc.c.~1~	Tue Jan 25 15:40:06 2000
> +++ 2.2.15pre4/mm/page_alloc.c	Thu Jan 27 09:51:35 2000
> @@ -236,16 +236,6 @@
>  	RMQUEUE_TYPE(order, 1);
>  	spin_unlock_irqrestore(&page_alloc_lock, flags);
>  
> -	/*
> -	 * If we can schedule, do so, and make sure to yield.
> -	 * We may be a real-time process, and if kswapd is
> -	 * waiting for us we need to allow it to run a bit.
> -	 */
> -	if (gfp_mask & __GFP_WAIT) {
> -		current->policy |= SCHED_YIELD;
> -		schedule();
> -	}
> -
>  nopage:
>  	return 0;
>  }

I agree that this (essentially useless) piece of code should
be taken out. However, I don't think this will fix the problem.

The real problem most likely hits when we're calling schedule()
to let kswapd do its job or when we're freeing pages ourselves
(and have to wait for I/O or cannot immediately grab the kernel
lock that's needed for do_try_to_freepages()).

regards,

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/