All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>,
	konrad.wilk@oracle.com, axboe@fb.com
Cc: "Julien Grall" <julien.grall@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Ian Campbell" <Ian.Campbell@citrix.com>,
	"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Subject: PAGE_SIZE (64KB), while block driver 'struct request' deals with < PAGE_SIZE (up to 44Kb). Was:Re: [RFC] Support of non-indirect grant backend on 64KB guest
Date: Fri, 21 Aug 2015 13:10:22 -0400	[thread overview]
Message-ID: <20150821171022.GL26663@l.oracle.com> (raw)
In-Reply-To: <55D74D03.9020301@citrix.com>

On Fri, Aug 21, 2015 at 05:08:35PM +0100, David Vrabel wrote:
> On 21/08/15 17:05, Konrad Rzeszutek Wilk wrote:
> > 
> > I have to concur with that. We can't mandate that ARM 64k page MUST use
> > indirect descriptors.
> 
> Then it has to be fixed in the block layer to allow < PAGE_SIZE segments
> and to get the block layer to split requests for blkfront.

Hey Jens,

I am hoping you can help us figure this problem out.

The Linux ARM is capable of using 4KB pages and 64KB pages. Our block
driver (xen-blkfront) was built with 4KB pages in mind and without using
any fancy flags (which some backends lack) the maximum amount of I/O it can
fit on a ring is 44KB.

This has the unfortunate effect that when the xen-blkfront
gets an 'struct request' it can have on page (64KB) and it can't actually
fit it on the ring! And the lowest segment size it advertises is PAGE_SIZE
(64KB). I believe Julien (who found this) tried initially advertising
smaller segment size than PAGE_SIZE (32KB). However looking at
__blk_segment_map_sg it looks to assume smallest size is PAGE_SIZE so
that would explain why it did not work.

One wya to make this work is for the driver (xen-blkfront) to split
the 'struct request' I/O in two internal requests.

But this has to be a normal problem. Surely there are other drivers
(MMC?) that can't handle PAGE_SIZE and have to break their I/Os.
Would it make sense for the common block code to be able to deal
with this?


Thank you!

  parent reply	other threads:[~2015-08-21 17:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18  6:29 [RFC] Support of non-indirect grant backend on 64KB guest Julien Grall
2015-08-18  7:09 ` Roger Pau Monné
2015-08-18  7:26   ` Jan Beulich
2015-08-18 18:45   ` Julien Grall
2015-08-19  8:50     ` Roger Pau Monné
2015-08-19 14:54       ` Julien Grall
2015-08-19 15:17         ` Roger Pau Monné
2015-08-19 15:52           ` Julien Grall
2015-08-19 23:44           ` Stefano Stabellini
2015-08-20  8:31             ` Roger Pau Monné
2015-08-20  9:43               ` David Vrabel
2015-08-20 16:16                 ` Julien Grall
2015-08-20 17:23                 ` Stefano Stabellini
2015-08-21 16:05                   ` Konrad Rzeszutek Wilk
2015-08-21 16:08                     ` David Vrabel
2015-08-21 16:49                       ` Stefano Stabellini
2015-08-21 17:10                       ` Konrad Rzeszutek Wilk [this message]
2015-08-27 17:51                         ` PAGE_SIZE (64KB), while block driver 'struct request' deals with < PAGE_SIZE (up to 44Kb). Was:Re: " Julien Grall
2015-09-04 14:04                           ` Stefano Stabellini
2015-09-04 15:41                             ` Konrad Rzeszutek Wilk
2015-09-04 16:15                               ` Julien Grall
2015-09-04 17:32                                 ` Konrad Rzeszutek Wilk
2015-09-04 22:05                                   ` Julien Grall
2015-08-20  9:37             ` Jan Beulich
2015-08-19  8:58     ` Jan Beulich
2015-08-19 15:25       ` Julien Grall
2015-08-20 17:42 ` David Vrabel
2015-08-21  1:30   ` Julien Grall
2015-08-21 16:07     ` Konrad Rzeszutek Wilk

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=20150821171022.GL26663@l.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=axboe@fb.com \
    --cc=david.vrabel@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.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.