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 doh/9] mempool simplify alloc
Date: Tue, 12 Apr 2005 22:53:52 +1000 [thread overview]
Message-ID: <425BC4E0.2030302@yahoo.com.au> (raw)
In-Reply-To: <425BC262.1070500@yahoo.com.au>
[-- Attachment #1: Type: text/plain, Size: 96 bytes --]
Whoops, this one should be 3/9. 3/9 should be 4/9, and so on.
--
SUSE Labs, Novell Inc.
quilt
[-- Attachment #2: mempool-simplify-alloc.patch --]
[-- Type: text/plain, Size: 2381 bytes --]
Mempool is pretty clever. Looks too clever for its own good.
It shouldn't really know so much about MM internals.
- don't guess about what effective page reclaim might involve.
- don't randomly flush out all dirty data if some unlikely thing
happens (alloc returns NULL). page reclaim can (sort of :P) handle
it.
I think the main motivation is trying to avoid pool->lock at all
costs. However the first allocation is attempted with __GFP_WAIT
cleared, so it will be 'can_try_harder' if it hits the page allocator.
So if allocation still fails, then we can probably afford to hit the
pool->lock - and what's the alternative? Try page reclaim and hit
zone->lru_lock?
Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au>
Index: linux-2.6/mm/mempool.c
===================================================================
--- linux-2.6.orig/mm/mempool.c 2005-04-12 22:47:02.000000000 +1000
+++ linux-2.6/mm/mempool.c 2005-04-12 22:47:02.000000000 +1000
@@ -198,36 +198,22 @@ void * mempool_alloc(mempool_t *pool, un
void *element;
unsigned long flags;
DEFINE_WAIT(wait);
- int gfp_nowait;
+ int gfp_temp;
+ might_sleep_if(gfp_mask & __GFP_WAIT);
+
gfp_mask |= __GFP_MEMPOOL;
gfp_mask |= __GFP_NORETRY; /* don't loop in __alloc_pages */
gfp_mask |= __GFP_NOWARN; /* failures are OK */
- gfp_nowait = gfp_mask & ~(__GFP_WAIT | __GFP_IO);
- might_sleep_if(gfp_mask & __GFP_WAIT);
+ gfp_temp = gfp_mask & ~__GFP_WAIT;
+
repeat_alloc:
- element = pool->alloc(gfp_nowait, pool->pool_data);
+
+ element = pool->alloc(gfp_temp, pool->pool_data);
if (likely(element != NULL))
return element;
- /*
- * If the pool is less than 50% full and we can perform effective
- * page reclaim then try harder to allocate an element.
- */
- mb();
- if ((gfp_mask & __GFP_FS) && (gfp_mask != gfp_nowait) &&
- (pool->curr_nr <= pool->min_nr/2)) {
- element = pool->alloc(gfp_mask, pool->pool_data);
- if (likely(element != NULL))
- return element;
- }
-
- /*
- * Kick the VM at this point.
- */
- wakeup_bdflush(0);
-
spin_lock_irqsave(&pool->lock, flags);
if (likely(pool->curr_nr)) {
element = remove_element(pool);
@@ -240,6 +226,8 @@ repeat_alloc:
if (!(gfp_mask & __GFP_WAIT))
return NULL;
+ /* Now start performing page reclaim */
+ gfp_temp = gfp_mask;
prepare_to_wait(&pool->wait, &wait, TASK_UNINTERRUPTIBLE);
mb();
if (!pool->curr_nr)
prev parent reply other threads:[~2005-04-12 13:06 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 ` [patch 3/9] no PF_MEMALLOC tinkering Nick Piggin
2005-04-12 19:57 ` 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 ` Nick Piggin [this message]
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=425BC4E0.2030302@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.