linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Boaz Harrosh <bharrosh@panasas.com>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	linux-scsi@vger.kernel.org, bhalevy@panasas.com,
	hch@infradead.org, akpm@linux-foundation.org,
	michaelc@cs.wisc.edu
Subject: Re: [PATCH v2] add bidi support for block pc requests
Date: Wed, 16 May 2007 20:13:27 +0200	[thread overview]
Message-ID: <20070516181325.GT23798@kernel.dk> (raw)
In-Reply-To: <1179338812.9602.4.camel@mulgrave.il.steeleye.com>

On Wed, May 16 2007, James Bottomley wrote:
> On Wed, 2007-05-16 at 19:53 +0200, Jens Axboe wrote:
> > The 1-page thing isn't a restriction as such, it's just an optimization.
> > The scatterlist allocated is purely a kernel entity, so you could do 4
> > contig pages and larger ios that way, if higher order allocations were
> > reliable.
> > 
> > But you are right in that we need to tweak the sg pool size so that it
> > ends up being a nice size, and not something that either spans a little
> > bit into a second page or doesn't fill a page nicely. On my x86-64 here,
> > a 128 segment sg table is exactly one page (looking at slabinfo). It
> > depends on the allocator whether that is just right, or just a little
> > too much due to management information.
> 
> Actually, if you look at the slab allocation algorithm (particularly
> calculate_slab_order()) you'll find it's not as simplistic as you're
> assuming ... what it actually does is try to allocate > 1 item in n
> pages to reduce the leftovers.

I'm not assuming anything, I was just being weary of having elements
that are exactly page sized if that would cause a bit of spill into a
second page. Don't tell me that PAGE_SIZE+10 (or whatever it might be)
would ever be an optimal allocation size.

> Additionally, remember that turning on redzoning, which seems to be
> quite popular nowadays, actually blows out the slab size calculations
> anyway.

Debugging will always throw these things out the window, we can't and
should not optimize for that. That goes for slab, and for lots of other
things.

> The bottom line is that it's better for us just to do exactly what we
> need and let the allocation algorithms figure out how to do it
> efficiently rather than trying to second guess them.

Partly true, it's also silly to just hardcore power-of-2 numbers without
ever bothering to look at what that results in (or even if it fits
normal use patterns).

We can easily be flexible, so it seems silly not to at least do a bit of
background research.

-- 
Jens Axboe


  reply	other threads:[~2007-05-16 18:14 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-08  2:25 [PATCH v2] add bidi support for block pc requests FUJITA Tomonori
2007-05-08 18:53 ` Boaz Harrosh
2007-05-08 20:01   ` James Bottomley
2007-05-09  7:46     ` Boaz Harrosh
2007-05-09 10:52       ` FUJITA Tomonori
2007-05-09 13:58         ` Boaz Harrosh
2007-05-09 14:54           ` FUJITA Tomonori
2007-05-09 14:55           ` James Bottomley
2007-05-09 16:54             ` Boaz Harrosh
2007-05-10  6:53               ` FUJITA Tomonori
2007-05-10  7:45                 ` FUJITA Tomonori
2007-05-10 12:37                   ` Boaz Harrosh
2007-05-10 13:01                     ` FUJITA Tomonori
2007-05-10 15:10                     ` Douglas Gilbert
2007-05-10 15:48                       ` Boaz Harrosh
2007-05-11 16:26                       ` James Bottomley
2007-05-16 17:29       ` Boaz Harrosh
2007-05-16 17:53         ` Jens Axboe
2007-05-16 18:06           ` James Bottomley
2007-05-16 18:13             ` Jens Axboe [this message]
2007-05-17  8:46               ` Boaz Harrosh
2007-05-17  2:57           ` FUJITA Tomonori
2007-05-17  5:48             ` Jens Axboe
2007-05-17  5:59               ` FUJITA Tomonori
2007-05-17  8:49                 ` Boaz Harrosh
2007-05-17 11:12                   ` FUJITA Tomonori
2007-05-17 17:37                     ` Benny Halevy
2007-05-24 16:37                     ` Boaz Harrosh
2007-05-24 16:46                       ` Boaz Harrosh
2007-05-24 16:47                       ` FUJITA Tomonori
2007-05-24 16:59                         ` Boaz Harrosh
2007-05-17 11:29                   ` FUJITA Tomonori
2007-05-17 13:27                   ` James Bottomley
2007-05-17 14:00                     ` Boaz Harrosh
2007-05-17 14:11                       ` FUJITA Tomonori
2007-05-17 15:49                         ` Boaz Harrosh
2007-06-01 20:21                           ` Jeff Garzik
2007-06-03  7:45                             ` Boaz Harrosh
2007-06-03 13:17                               ` James Bottomley
2007-07-07 15:27                                 ` Jeff Garzik
2007-07-07 15:42                                   ` James Bottomley
2007-07-07 16:59                                     ` Jeff Garzik
2007-05-09 10:49     ` FUJITA Tomonori

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=20070516181325.GT23798@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhalevy@panasas.com \
    --cc=bharrosh@panasas.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    /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).