From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Jens Axboe <axboe@suse.de>,
"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 20:23:56 +1000 [thread overview]
Message-ID: <42492CBC.1060406@yahoo.com.au> (raw)
In-Reply-To: <1112091026.6282.43.camel@laptopd505.fenrus.org>
Arjan van de Ven wrote:
> On Tue, 2005-03-29 at 19:19 +1000, Nick Piggin wrote:
>
>>- removes the relock/retry merge mechanism in __make_request if we
>> aren't able to get the GFP_ATOMIC allocation. Just fall through
>> and assume the chances of getting a merge will be small (is this
>> a valid assumption? Should measure it I guess).
>
>
> this may have a potential problem; if the vm gets in trouble, you
> suddenly start to generate worse IO patterns, which means IO performance
> goes down right when it's most needed.....
>
Sorry my wording was incorrect. It currently *always* retries the
merge if it had at first failed, and after the patch, we never retry.
So it should not result in behavioural shifts when there is a VM load
is high.
It seems to be a clear source of problems for Kenneth though, because
his workload appears to have almost zero merges, so he'll always be
invoking the merge logic twice.
I agree there is potential for subtle interactions. But generally the
block layer is surprisingly well behaved in my experience.
As Jens said, the complete removal of the GFP_ATOMIC allocation probably
has the most potential for problems in this regard, although bios are not
using GFP_ATOMIC allocations, so I would be a little surprised if it made
a really noticable difference.
next prev parent reply other threads:[~2005-03-29 10:25 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
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 [this message]
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=42492CBC.1060406@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=arjan@infradead.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.