From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Jens Axboe <axboe@suse.de>, Andrew Morton <akpm@osdl.org>
Cc: "Chen, Kenneth W" <kenneth.w.chen@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [patch] use cheaper elv_queue_empty when unplug a device
Date: Tue, 29 Mar 2005 19:50:00 +1000 [thread overview]
Message-ID: <424924C8.1000608@yahoo.com.au> (raw)
In-Reply-To: <20050329092819.GK16636@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]
Jens Axboe wrote:
> Looks good, I've been toying with something very similar for a long time
> myself.
>
> The unplug change is a no-brainer.
Yep - I may have even stolen it from you (or someone) from a patch
which had been forgotten. I can't remember for sure, but it is trivial
enough that anyone could come up with it if they noticed, so I won't
worry about attribution ;)
> The retry stuff i __make_request()
> will make no real difference on 'typical' hardware, when it was
> introduced in 2.4.x it was very useful on slower devices like dvd-rams.
> The batch wakeups should take care of this.
>
OK cool, that was the main thing I was unsure of.
> The atomic-vs-blocking allocation should be tested. I'd really like it
> to be a "don't dive into the vm very much, just wait on the mempool"
> type allocation, so we are not at the mercy of long vm reclaim times
> hurting the latencies here.
>
Ahh yes I forgot it was backing it with a mempool. The problem I see
with that is that GFP_ATOMIC allocations eat into the mm's "atomic
reserve" pool (main use: networking), which would be nice not to.
So long as we are sure that we'll *eventually* fall back to the mempool,
it should be OK (but I still agree should have testing) - that isn't
entirely clear though, because the page allocator infinitely loops on
small allocations unless __GFP_NORETRY is set.
Andrew - tell me I'm missing something?
[-- Attachment #2: mempool-can-fail.patch --]
[-- Type: text/plain, Size: 683 bytes --]
---
linux-2.6-npiggin/mm/mempool.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletion(-)
diff -puN mm/mempool.c~mempool-can-fail mm/mempool.c
--- linux-2.6/mm/mempool.c~mempool-can-fail 2005-03-29 19:45:02.000000000 +1000
+++ linux-2.6-npiggin/mm/mempool.c 2005-03-29 19:48:05.000000000 +1000
@@ -198,7 +198,10 @@ void * mempool_alloc(mempool_t *pool, in
void *element;
unsigned long flags;
DEFINE_WAIT(wait);
- int gfp_nowait = gfp_mask & ~(__GFP_WAIT | __GFP_IO);
+ int gfp_nowait;
+
+ gfp_mask |= __GFP_NORETRY; /* don't loop in __alloc_pages */
+ gfp_nowait = gfp_mask & ~(__GFP_WAIT | __GFP_IO);
might_sleep_if(gfp_mask & __GFP_WAIT);
repeat_alloc:
_
next prev parent reply other threads:[~2005-03-29 9:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-29 2:53 [patch] use cheaper elv_queue_empty when unplug a device Chen, Kenneth W
2005-03-29 8:06 ` Jens Axboe
2005-03-29 9:19 ` Nick Piggin
2005-03-29 9:21 ` Nick Piggin
2005-03-29 9:28 ` Jens Axboe
2005-03-29 9:50 ` Nick Piggin [this message]
2005-03-29 10:06 ` Nick Piggin
2005-03-30 0:57 ` Nick Piggin
2005-03-30 8:11 ` Jens Axboe
2005-04-08 9:45 ` Jens Axboe
2005-04-08 9:55 ` Nick Piggin
2005-04-08 10:02 ` Jens Axboe
2005-04-08 10:22 ` Nick Piggin
2005-03-29 10:10 ` Arjan van de Ven
2005-03-29 10:19 ` Jens Axboe
2005-03-29 10:23 ` Nick Piggin
2005-03-29 13:15 ` Jens Axboe
2005-03-30 0:07 ` Nick Piggin
2005-03-29 19:02 ` Chen, Kenneth W
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=424924C8.1000608@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.