linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Dmitry Monakhov <dmonakhov@sw.ru>,
	torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Mel Gorman <mel@skynet.ie>,
	William Lee Irwin III <wli@holomorphy.com>,
	David Chinner <dgc@sgi.com>, Badari Pulavarty <pbadari@gmail.com>,
	Maxim Levitsky <maximlevitsky@gmail.com>,
	Fengguang Wu <fengguang.wu@gmail.com>,
	swin wang <wangswin@gmail.com>,
	totty.lu@gmail.com, "H. Peter Anvin" <hpa@zytor.com>,
	joern@lazybastard.org,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [11/36] Use page_cache_xxx in fs/buffer.c
Date: Fri, 31 Aug 2007 10:12:01 +0200	[thread overview]
Message-ID: <20070831081201.GO29452@kernel.dk> (raw)
In-Reply-To: <Pine.LNX.4.64.0708310049110.14743@schroedinger.engr.sgi.com>

On Fri, Aug 31 2007, Christoph Lameter wrote:
> On Fri, 31 Aug 2007, Jens Axboe wrote:
> 
> > They have nothing to do with each other, you are mixing things up. It
> > has nothing to do with the device being able to dma into that memory or
> > not, we have fine existing infrastructure to handle that. But different
> > hardware have different characteristics on what a single segment is. You
> > can say "a single segment cannot cross a 32kb boundary". So from the
> > example above, your single 64k page may need to be split into two
> > segments. Or it could have a maximum segment size of 32k, in which case
> > it would have to be split as well.
> > 
> > Do you see what I mean now?
> 
> Ok. So another solution maybe to limit the blocksizes that can be used 
> with a device?

That'd work for creation, but not for moving things around.

> > > How do we split that up today? We could add processing to submit_bio
> > > to check for the boundary and create two bios.
> > 
> > But we do not split them up today - see what I wrote! Today we impose
> > the restriction that a device must be able to handle a single "normal"
> > page, and if it can't do that, it has to split it up itself.
> > 
> > But yes, you would have to create some out-of-line function to use
> > bio_split() until you have chopped things down enough. It's not a good
> > thing for performance naturally, but if we consider this a "just make it
> > work" fallback, I don't think it's too bad. You want to make a note of
> > that it is happening though, so people realize that it is happening.
> 
> Hmmmm.. We could keep the existing scheme too and check that device 
> drivers split things up if they are too large? Isnt it possible today
> to create a huge bio of 2M for huge pages and send it to a device?

Not sure, aren't the constituents of compound pages the basis for IO?

-- 
Jens Axboe


  reply	other threads:[~2007-08-31  8:12 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070828190551.415127746@sgi.com>
     [not found] ` <20070828190735.292638294@sgi.com>
2007-08-30  0:11   ` [31/36] Large Blocksize: Core piece Mingming Cao
2007-08-30  0:12     ` Christoph Lameter
2007-08-30  0:47     ` [RFC 1/4] Large Blocksize support for Ext2/3/4 Mingming Cao
2007-08-30  0:59       ` Christoph Lameter
2007-09-01  0:01       ` Mingming Cao
2007-09-01  0:12       ` [RFC 1/2] JBD: slab management support for large block(>8k) Mingming Cao
2007-09-01 18:39         ` Christoph Hellwig
2007-09-02 11:40           ` Christoph Lameter
2007-09-02 15:28             ` Christoph Hellwig
2007-09-03  7:55               ` Christoph Lameter
2007-09-03 13:40                 ` Christoph Hellwig
2007-09-03 19:31                   ` Christoph Lameter
2007-09-03 19:33                     ` Christoph Hellwig
2007-09-14 18:53                       ` [PATCH] JBD slab cleanups Mingming Cao
2007-09-14 18:58                         ` Christoph Lameter
2007-09-17 19:29                         ` Mingming Cao
2007-09-17 19:34                           ` Christoph Hellwig
2007-09-17 22:01                           ` Badari Pulavarty
2007-09-17 22:57                             ` Mingming Cao
2007-09-18  9:04                               ` Christoph Hellwig
2007-09-18 16:35                                 ` Mingming Cao
2007-09-18 18:04                                   ` Dave Kleikamp
2007-09-19  1:00                                     ` Mingming Cao
2007-09-19  2:19                                       ` Andrew Morton
2007-09-19 19:15                                         ` Mingming Cao
2007-09-19 19:22                                           ` [PATCH] JBD: use GFP_NOFS in kmalloc Mingming Cao
2007-09-19 21:34                                             ` Andrew Morton
2007-09-19 21:55                                               ` Mingming Cao
2007-09-20  4:25                                             ` Andreas Dilger
2007-09-19 19:26                                           ` [PATCH] JBD slab cleanups Dave Kleikamp
2007-09-19 19:28                                             ` Dave Kleikamp
2007-09-19 20:47                                               ` Mingming Cao
2007-09-19 19:48                                           ` Andreas Dilger
2007-09-19 22:03                                             ` Mingming Cao
2007-09-01  0:12       ` [RFC 2/2] JBD: blocks reservation fix for large block support Mingming Cao
2007-08-30  0:47     ` [RFC 2/4]ext2: fix rec_len overflow with 64KB block size Mingming Cao
     [not found] ` <20070828190730.220393749@sgi.com>
2007-08-30  9:20   ` [11/36] Use page_cache_xxx in fs/buffer.c Dmitry Monakhov
2007-08-30 18:14     ` Christoph Lameter
2007-08-31  1:47       ` Christoph Lameter
2007-08-31  6:56         ` Jens Axboe
2007-08-31  7:03           ` Christoph Lameter
2007-08-31  7:11             ` Jens Axboe
2007-08-31  7:17               ` Christoph Lameter
2007-08-31  7:26                 ` Jens Axboe
2007-08-31  7:33                   ` Christoph Lameter
2007-08-31  7:43                     ` Jens Axboe
2007-08-31  7:52                       ` Christoph Lameter
2007-08-31  8:12                         ` Jens Axboe [this message]
2007-08-31 15:22                           ` Christoph Lameter
2007-08-31 16:35                             ` Jörn Engel
2007-08-31 19:00                             ` Jens Axboe
2007-08-31  8:36                         ` Dmitry Monakhov
2007-08-31 15:28                           ` Christoph Lameter
     [not found] ` <20070828192034.GA13883@lst.de>
     [not found]   ` <Pine.LNX.4.64.0708281254070.16473@schroedinger.engr.sgi.com>
2007-09-01  1:11     ` [00/36] Large Blocksize Support V6 Christoph Lameter
2007-09-01 19:17 ` Peter Zijlstra
2007-09-02 11:44   ` Christoph Lameter

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=20070831081201.GO29452@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=clameter@sgi.com \
    --cc=dgc@sgi.com \
    --cc=dmonakhov@sw.ru \
    --cc=ebiederm@xmission.com \
    --cc=fengguang.wu@gmail.com \
    --cc=hch@lst.de \
    --cc=hpa@zytor.com \
    --cc=joern@lazybastard.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    --cc=mel@skynet.ie \
    --cc=pbadari@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=totty.lu@gmail.com \
    --cc=wangswin@gmail.com \
    --cc=wli@holomorphy.com \
    /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).