Re: [RFC] gfp_mask for address_space

Re: [RFC] gfp_mask for address_space

[Stephen C. Tweedie]

Hi,

On Fri, Dec 01, 2000 at 03:59:44PM -0500, Alexander Viro wrote:
> 	Guys, what about adding into address_space a new field - gfp_mask?
> Changes required:
> 	a) new argument for page_cache_alloc() - address_space we want the
> page to go in. NULL for anonymous pages. (9 lines).
> 	b) when we initialize the ->i_data we should set ->i_data.gfp_mask to
> GFP_HIGHUSER (1 line)
> 	c) when we set the loop device we could memorize the current gfp_mask
> of the ->i_mapping of that file and set it to GFP_BUFFER.
> 	d) restore the old value upon losetup -d

There are other things we could do with something like this --- for
example, localising cache allocations on NUMA.

However, it doesn't actually fix all of the problems.  We still have
balance_dirty() deadlocks even if we avoid memory allocation loops.
NBD to localhost shows this up particularly easily, for example.

For 2.5, I think that the NBD problem can only really be laid to rest
by making bdflush fully async, so that things like the nbd server can
still run a balance_dirty() without deadlocking.  

The problem right now is that the balance_dirty() inside the nbd
server can result in it attempting to flush out dirty nbd buffers, so
we have the nbd device blocked on the nbd server, the nbd server
dirtying local disk buffer_heads, and the dirty buffer code blocking
on other dirty nbd buffers.)

The more we can make the VM flush and dirty-balancing code
asynchronous, the more we can both remove these deadlocks, AND cater
cleanly with multiple devices whose IO rates are vastly different.
(Things get really ugly if you start filling memory with dirty buffers
for slow devices like MO or floppies right now.)

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: [RFC] gfp_mask for address_space

[Alexander Viro]

On Mon, 4 Dec 2000, Stephen C. Tweedie wrote:

> However, it doesn't actually fix all of the problems.  We still have
> balance_dirty() deadlocks even if we avoid memory allocation loops.

I know. However, these are somewhat easier to kill. E.g. we could give
weights to devices (normal => 0, loopback over file on device of level
n => n+1) and split bdflush into per-weight threads. Then we have an
obvious hierarchy (activity of bdflush[n] can't lead to new dirty bh
of weight n and above).
 
> The problem right now is that the balance_dirty() inside the nbd
> server can result in it attempting to flush out dirty nbd buffers, so
> we have the nbd device blocked on the nbd server, the nbd server
> dirtying local disk buffer_heads, and the dirty buffer code blocking
> on other dirty nbd buffers.)

Ditto for loop and the same method can be applied... 

I'm actually more interested in experimenting with bitmaps in page
cache - making it GFP_BUFFER should be deadlock-safe, AFAICS, and
ext2/balloc.c would benefit big way from switching to that...
							Cheers,
								Al

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/