gfp_mask for address_space

RFC Stephen C. Tweedie 2 participants 2 messages Dec 4, 2000 2 messages not in the archive Memory management

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Stephen C. Tweedie

author

2000-12-04 13:40 UTC #2 lore raw

Hi,

Quoted 9 lines · Alexander Viro

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 [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Alexander Viro

2000-12-04 13:56 UTC #3 lore raw

Quoted 2 lines · Stephen C. Tweedie

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).

Quoted 5 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/