linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alasdair G Kergon <agk@redhat.com>
To: Vasily Averin <vvs@sw.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	dm-devel@redhat.com, linux-kernel@vger.kernel.org,
	devel@openvz.org, stable@kernel.org,
	Jens Axboe <jens.axboe@oracle.com>, Milan Broz <mbroz@redhat.com>
Subject: Re: [dm-devel] Re: dm: bounce_pfn limit added
Date: Wed, 31 Oct 2007 02:01:33 +0000	[thread overview]
Message-ID: <20071031020133.GL10006@agk.fab.redhat.com> (raw)
In-Reply-To: <20071030232617.GJ10006@agk.fab.redhat.com>

On Tue, Oct 30, 2007 at 11:26:17PM +0000, Alasdair G Kergon wrote:
> ) DM doesn't need to bounce bio's on its own, but the block layer defaults
> ) to that in blk_queue_make_request(). The lower level drivers should
> ) bounce ios themselves, that is what they need to do if not layered below
> ) dm anyways.

So currently we treat bounce_pfn as a property that does not need to be
propagated through the stack.

But is that the right approach?
- Is there a blk_queue_bounce() missing either from dm or elsewhere?
  (And BTW can the bio_alloc() that lurks within lead to deadlock?)

Firstly, what's going wrong?
- What is the dm table you are using?  (output of 'dmsetup table')
  - Which dm targets and with how many underlying devices?
- Which underlying driver?
- Is this direct I/O to the block device from userspace, or via some
filesystem or what?

Presumably you've shown the problem goes away when the dm device is
removed from the stack.
What if you swap in alternative dm targets, e.g. if it's linear,
try multipath (round-robin, one path)?
 
Alasdair
-- 
agk@redhat.com

  reply	other threads:[~2007-10-31  2:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29  6:31 dm: bounce_pfn limit added Vasily Averin
2007-10-30 20:11 ` Andrew Morton
2007-10-30 23:26   ` [dm-devel] " Alasdair G Kergon
2007-10-31  2:01     ` Alasdair G Kergon [this message]
2007-10-31  2:11       ` Alasdair G Kergon
2007-10-31  7:13       ` Vasily Averin
2007-10-31  7:36         ` Hannes Reinecke
2007-10-31 22:00           ` Kiyoshi Ueda
2007-11-01  0:00             ` Alasdair G Kergon

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=20071031020133.GL10006@agk.fab.redhat.com \
    --to=agk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=devel@openvz.org \
    --cc=dm-devel@redhat.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbroz@redhat.com \
    --cc=stable@kernel.org \
    --cc=vvs@sw.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).