linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Mark Lord <lkml@rtr.ca>
Cc: Jens Axboe <axboe@kernel.dk>,
	IDE/ATA development list <linux-ide@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	James Bottomley <James.Bottomley@steeleye.com>
Subject: Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
Date: Thu, 13 Dec 2007 11:42:21 -0700	[thread overview]
Message-ID: <20071213184221.GP26334@parisc-linux.org> (raw)
In-Reply-To: <47617C07.3020501@rtr.ca>

On Thu, Dec 13, 2007 at 01:37:59PM -0500, Mark Lord wrote:
> The problem is, the block layer *never* sends an SG entry larger than 8192 
> bytes,
> and even that size is exceptionally rare.  Nearly all I/O segments are 4096 
> bytes,
> so I never see a single I/O larger than 512KB (128 * 4096).
> 
> If I patch various parts of block and SCSI, this limit doesn't budge,
> but when I change the hardware PRD limit in libata, it scales by exactly
> whatever I set the new value to.  This tells me that adjacent I/O segments
> are not being combined.
> 
> I thought that QUEUE_FLAG_CLUSTER (aka. SCSI host .use_clustering=1) should
> result in adjacent single pages being combined into larger physical 
> segments?

I was recently debugging a driver and noticed that consecutive pages in
an sg list are in the reverse order.  ie first you get page 918, then
917, 916, 915, 914, etc.  I vaguely remember James having patches to
correct this, but maybe they weren't merged?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2007-12-13 18:42 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 18:36 QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Mark Lord
2007-12-13 18:37 ` Mark Lord
2007-12-13 18:42   ` Matthew Wilcox [this message]
2007-12-13 18:46     ` James Bottomley
2007-12-13 18:48   ` Mark Lord
2007-12-13 18:53     ` Matthew Wilcox
2007-12-13 19:03       ` Mark Lord
2007-12-13 19:26         ` Jens Axboe
2007-12-13 19:30           ` Mark Lord
2007-12-13 19:32             ` Mark Lord
2007-12-13 19:39               ` Jens Axboe
2007-12-13 19:42                 ` Mark Lord
2007-12-13 19:53                   ` Jens Axboe
2007-12-13 19:59                     ` Mark Lord
2007-12-13 20:05                       ` Jens Axboe
2007-12-13 20:02                     ` Jens Axboe
2007-12-13 20:06                       ` Mark Lord
2007-12-13 20:09                         ` Jens Axboe
2007-12-13 20:14                           ` Mark Lord
2007-12-13 20:18                             ` Mark Lord
2007-12-13 20:21                             ` Jens Axboe
2007-12-13 22:02                           ` Andrew Morton
2007-12-13 22:15                             ` James Bottomley
2007-12-13 22:29                               ` Andrew Morton
2007-12-13 22:33                                 ` Mark Lord
2007-12-13 23:13                                   ` Mark Lord
2007-12-14  0:05                                     ` Mark Lord
2007-12-14  0:30                                       ` Mark Lord
2007-12-14  0:37                                         ` Andrew Morton
2007-12-14  0:42                                           ` Mark Lord
2007-12-14  0:46                                             ` [PATCH] fix page_alloc for larger I/O segments (improved) Mark Lord
2007-12-14  0:57                                               ` James Bottomley
2007-12-14  1:11                                                 ` Andrew Morton
2007-12-14  2:23                                                   ` Mark Lord
2007-12-14 17:42                                               ` Mel Gorman
2007-12-14 18:07                                                 ` Mark Lord
2007-12-16 21:56                                                   ` Mel Gorman
2007-12-14 18:13                                                 ` Matthew Wilcox
2007-12-14 18:30                                                   ` Mark Lord
2007-12-20 22:37                                                   ` Matthew Wilcox
2007-12-14  0:47                                             ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Mark Lord
2007-12-14 11:50                                           ` Mel Gorman
2007-12-14 13:57                                             ` Mark Lord
2007-12-14  0:40                                         ` [PATCH] fix page_alloc for larger I/O segments Mark Lord
2007-12-14  1:03                                           ` Andrew Morton
2007-12-14  4:00                                             ` Matthew Wilcox
2007-12-13 22:17                             ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Jens Axboe
2007-12-13 22:02                           ` VM allocates pages in reverse order again Matthew Wilcox
2007-12-13 19:37             ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Jens Axboe
2007-12-13 19:53           ` Mark Lord

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=20071213184221.GP26334@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=James.Bottomley@steeleye.com \
    --cc=axboe@kernel.dk \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lkml@rtr.ca \
    /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).