linux-kernel - Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1197571563.3154.41.camel@localhost.localdomain>
Date:	Thu, 13 Dec 2007 13:46:03 -0500
From:	James Bottomley <James.Bottomley@...elEye.com>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Mark Lord <lkml@....ca>, Jens Axboe <axboe@...nel.dk>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?


On Thu, 2007-12-13 at 11:42 -0700, Matthew Wilcox wrote:
> 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?

Yes, they were ... it was actually Bill Irwin's patch.  The old problem
was that we fault allocations in reverse order (because we were taking
from the end of the zone list).  I can't remember when his patches went
in, but it was several years ago.  After they did, I was getting a 33%
chance of physical merging (as opposed to zero before).  Probably
someone redid the vm or the zones without understanding this and we've
gone back to the original position.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/