diff options
| author | Andrew Morton <akpm@zip.com.au> | 2002-05-19 02:23:27 -0700 |
|---|---|---|
| committer | Arnaldo Carvalho de Melo <acme@conectiva.com.br> | 2002-05-19 02:23:27 -0700 |
| commit | a25364526006361b7e7e011ce488cb46e89dd3ef (patch) | |
| tree | 3ff05b46aaeb9b8c47c413b7f462d2a047d9ba10 /include/linux/raid | |
| parent | 5409c2b52ffea911ba1e47b5cbf8d911efb5d0c6 (diff) | |
[PATCH] remove PG_launder
Removal of PG_launder.
It's not obvious (to me) why this ever existed. If it's to prevent
deadlocks then I'd like to know who was performing __GFP_FS allocations
while holding a page lock?
But in 2.5, the only memory allocations which are performed when the
caller holds PG_writeback against an unsubmitted page are those which
occur inside submit_bh(). There will be no __GFS_FS allocations in
that call chain.
Removing PG_launder means that memory allocators can block on any
PageWriteback() page at all, which reduces the risk of very long list
walks inside pagemap_lru_lock in shrink_cache().
Diffstat (limited to 'include/linux/raid')
0 files changed, 0 insertions, 0 deletions
