Messages in this thread | | | Subject | Re: Bounce buffer deadlock | Date | Sat, 30 Jun 2001 13:23:37 -0500 | From | Steve Lord <> |
| |
> > On Sat, 30 Jun 2001, Steve Lord wrote: > > > > OK, sounds reasonable, time to go download and merge again I guess! > > For 2.4.7 or so, I'll make a backwards-compatibility define (ie make > GFP_BUFFER be the same as the new GFP_NOIO, which is the historical > behaviour and the anally safe value, if not very efficient), but I'm > planning on releasing 2.4.6 without it, to try to flush out people who are > able to take advantage of the new extended semantics out of the > woodworks.. > > Linus
Consider XFS flushed out (once I merge). This, for us, is the tricky part:
torvalds@transmeta.com said: >> That allows us to do the best we can - still flushing out dirty >> buffers when that's ok (like when a filesystem wants more memory), and >> giving the allocator better control over exactly _what_ he objects to.
XFS introduces the concept of the low level flush of a buffer not always being really a low level flush, since a delayed allocate buffer can end up reentering the filesystem in order to create the true on disk allocation. This in turn can cause a transaction and more memory allocations. The really nasty case we were using GFP_BUFFER for is a memory allocation which is from within a transaction, we cannot afford to have another transaction start out of the bottom of memory allocation as it may require resources locked by the transaction which is allocating memory.
Steve
- 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/
| |