From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@osdl.org>
Cc: Jens Axboe <axboe@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Chen, Kenneth W" <kenneth.w.chen@intel.com>
Subject: [patch 3/9] no PF_MEMALLOC tinkering
Date: Tue, 12 Apr 2005 22:49:22 +1000 [thread overview]
Message-ID: <425BC3D2.3020909@yahoo.com.au> (raw)
In-Reply-To: <425BC262.1070500@yahoo.com.au>
[-- Attachment #1: Type: text/plain, Size: 32 bytes --]
3/9
--
SUSE Labs, Novell Inc.
[-- Attachment #2: no-PF_MEMALLOC-tinkering.patch --]
[-- Type: text/plain, Size: 3426 bytes --]
PF_MEMALLOC is really not a tool for tinkering. It is pretty specifically
used to prevent recursion into page reclaim, and to prevent low memory
deadlocks.
The mm/swap_state.c code was the only legitimate tinkerer. Its concern
was addressed by the previous patch.
Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au>
Index: linux-2.6/mm/swap_state.c
===================================================================
--- linux-2.6.orig/mm/swap_state.c 2005-04-12 22:05:44.000000000 +1000
+++ linux-2.6/mm/swap_state.c 2005-04-12 22:26:12.000000000 +1000
@@ -143,7 +143,6 @@ void __delete_from_swap_cache(struct pag
int add_to_swap(struct page * page)
{
swp_entry_t entry;
- int pf_flags;
int err;
if (!PageLocked(page))
@@ -154,30 +153,11 @@ int add_to_swap(struct page * page)
if (!entry.val)
return 0;
- /* Radix-tree node allocations are performing
- * GFP_ATOMIC allocations under PF_MEMALLOC.
- * They can completely exhaust the page allocator.
- *
- * So PF_MEMALLOC is dropped here. This causes the slab
- * allocations to fail earlier, so radix-tree nodes will
- * then be allocated from the mempool reserves.
- *
- * We're still using __GFP_HIGH for radix-tree node
- * allocations, so some of the emergency pools are available,
- * just not all of them.
- */
-
- pf_flags = current->flags;
- current->flags &= ~PF_MEMALLOC;
-
/*
* Add it to the swap cache and mark it dirty
*/
err = __add_to_swap_cache(page, entry, GFP_ATOMIC|__GFP_NOWARN);
- if (pf_flags & PF_MEMALLOC)
- current->flags |= PF_MEMALLOC;
-
switch (err) {
case 0: /* Success */
SetPageUptodate(page);
Index: linux-2.6/drivers/md/dm-crypt.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-crypt.c 2005-04-12 22:05:44.000000000 +1000
+++ linux-2.6/drivers/md/dm-crypt.c 2005-04-12 22:26:12.000000000 +1000
@@ -331,25 +331,14 @@ crypt_alloc_buffer(struct crypt_config *
struct bio *bio;
unsigned int nr_iovecs = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
int gfp_mask = GFP_NOIO | __GFP_HIGHMEM;
- unsigned long flags = current->flags;
unsigned int i;
- /*
- * Tell VM to act less aggressively and fail earlier.
- * This is not necessary but increases throughput.
- * FIXME: Is this really intelligent?
- */
- current->flags &= ~PF_MEMALLOC;
-
if (base_bio)
bio = bio_clone(base_bio, GFP_NOIO);
else
bio = bio_alloc(GFP_NOIO, nr_iovecs);
- if (!bio) {
- if (flags & PF_MEMALLOC)
- current->flags |= PF_MEMALLOC;
+ if (!bio)
return NULL;
- }
/* if the last bio was not complete, continue where that one ended */
bio->bi_idx = *bio_vec_idx;
@@ -386,9 +375,6 @@ crypt_alloc_buffer(struct crypt_config *
size -= bv->bv_len;
}
- if (flags & PF_MEMALLOC)
- current->flags |= PF_MEMALLOC;
-
if (!bio->bi_size) {
bio_put(bio);
return NULL;
Index: linux-2.6/fs/mpage.c
===================================================================
--- linux-2.6.orig/fs/mpage.c 2005-04-12 22:05:44.000000000 +1000
+++ linux-2.6/fs/mpage.c 2005-04-12 22:26:12.000000000 +1000
@@ -105,11 +105,6 @@ mpage_alloc(struct block_device *bdev,
bio = bio_alloc(gfp_flags, nr_vecs);
- if (bio == NULL && (current->flags & PF_MEMALLOC)) {
- while (!bio && (nr_vecs /= 2))
- bio = bio_alloc(gfp_flags, nr_vecs);
- }
-
if (bio) {
bio->bi_bdev = bdev;
bio->bi_sector = first_sector;
next prev parent reply other threads:[~2005-04-12 13:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-12 12:43 [patch 0/9] various (mainly mempool fixes and block layer improvements) Nick Piggin
2005-04-12 12:48 ` [patch 1/9] GFP_ZERO fix Nick Piggin
2005-04-12 19:47 ` Andrew Morton
2005-04-13 1:02 ` Nick Piggin
2005-04-14 10:59 ` Manfred Spraul
2005-04-12 12:48 ` [patch 2/9] mempool gfp flag Nick Piggin
2005-04-12 19:50 ` Andrew Morton
2005-04-13 1:03 ` Nick Piggin
2005-04-12 12:49 ` Nick Piggin [this message]
2005-04-12 19:57 ` [patch 3/9] no PF_MEMALLOC tinkering Andrew Morton
2005-04-13 1:13 ` Nick Piggin
2005-04-12 12:49 ` [patch 4/9] blk: no memory barrier Nick Piggin
2005-04-12 12:50 ` [patch 5/9] blk: branch hints Nick Piggin
2005-04-12 12:50 ` [patch 6/9] blk: unplug later Nick Piggin
2005-04-12 19:58 ` Andrew Morton
2005-04-13 1:32 ` Nick Piggin
2005-04-13 10:20 ` Jens Axboe
2005-04-12 12:51 ` [patch 7/9] blk: efficiency improvements Nick Piggin
2005-04-12 12:52 ` [patch 0/9] blk: reduce locking Nick Piggin
2005-04-12 12:53 ` [patch doh/9] mempool simplify alloc Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=425BC3D2.3020909@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.