Allocating a buffer head during out of memory is always been deadlock
prone, 2.2 always had the same problem too. I'm not sure why you are
telling me this, I didn't changed anything that happens to be in the
swapout path (besides removing the deadlock in create_bounces with
evolution of first Ingo's patch but that is not specific to the
swapout). I only changed the getblk path (which is not used by the
swapout, at least unless you swapout on a file not on a blkdev, but even
in that case the change is fine).
About yelding interally to alloc_pages it would make sense if we
had a private pool internally to the allocator, otherwise with current
code you definitely want to return a faliure fast to the caller so the
caller will try the private pool before the yield.
btw in the below patch __GFP_FAIL is a noop.
>
> -ben
>
> diff -ur v2.4.4-ac9/include/linux/mm.h work/include/linux/mm.h
> --- v2.4.4-ac9/include/linux/mm.h Mon May 14 15:22:17 2001
> +++ work/include/linux/mm.h Mon May 14 18:33:21 2001
> @@ -528,7 +528,7 @@
>
>
> #define GFP_BOUNCE (__GFP_HIGH | __GFP_FAIL)
> -#define GFP_BUFFER (__GFP_HIGH | __GFP_WAIT)
> +#define GFP_BUFFER (__GFP_HIGH | __GFP_FAIL | __GFP_WAIT)
> #define GFP_ATOMIC (__GFP_HIGH)
> #define GFP_USER ( __GFP_WAIT | __GFP_IO)
> #define GFP_HIGHUSER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHMEM)
> diff -ur v2.4.4-ac9/mm/vmscan.c work/mm/vmscan.c
> --- v2.4.4-ac9/mm/vmscan.c Mon May 14 14:57:00 2001
> +++ work/mm/vmscan.c Mon May 14 16:43:05 2001
> @@ -636,6 +636,12 @@
> */
> shortage = free_shortage();
> if (can_get_io_locks && !launder_loop && shortage) {
> + if (gfp_mask & __GFP_WAIT) {
> + __set_current_state(TASK_RUNNING);
> + current->policy |= SCHED_YIELD;
> + schedule();
> + }
> +
> launder_loop = 1;
>
> /*
>
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/