On Sat, 9 Jan 1999 03:34:56 +0100 (CET), Andrea Arcangeli
<andrea@e-mind.com> said:
> Hi Stephen!
> On Sat, 9 Jan 1999, Stephen C. Tweedie wrote:
>> deadlock. The easiest way I can see of achieving something like this is
>> to set current->flags |= PF_MEMALLOC while we hold the superblock lock,
> Hmm, we must not avoid shrink_mmap() to run. So I see plain wrong to set
> the PF_MEMALLOC before call __get_free_pages(). Very cleaner to use
> GFP_ATOMIC to achieve the same effect btw ;).
No, there are about a squillion possible places where we might try to
allocate memory with the superblock lock; updating them all to make
the gfp parameter conditional is gross!
Anyway, the whole point of PF_MEMALLOC is that it says we are
currently in the middle of an operation which has subtle deadlock or
stack overflow semantics wrt allocations, so always try to make
allocations from the free list. In this case, the number of such
allocations we expect is small, so this is reasonable. And yes, using
a new flag as opposed to PF_MEMALLOC would allow us to continue to
shrink_mmap (and in fact also to unmap clean pages) while preventing
recursive IO.
--Stephen
-
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/