linux-kernel - Re: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1216575211.4199.35.camel@localhost.localdomain>
Date:	Sun, 20 Jul 2008 12:33:31 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	David Miller <davem@...emloft.net>
Cc:	mpatocka@...hat.com, fujita.tomonori@....ntt.co.jp,
	jens.axboe@...cle.com, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, linux-parisc@...r.kernel.org
Subject: Re: [PATCH] block: fix q->max_segment_size checking in
	blk_recalc_rq_segments about VMERGE

On Sun, 2008-07-20 at 10:23 -0700, David Miller wrote:
> From: James Bottomley <James.Bottomley@...senPartnership.com>
> Date: Sun, 20 Jul 2008 09:52:25 -0500
> 
> > Since we're using it successfully in parisc, I don't want the block code
> > removed, but I don't see a reason to force other architectures to use
> > it.
> > 
> > However, it has two use cases.  One is the legacy one of making rather
> > dumb I/O cards perform better (which is the primary on on parisc), but
> > there is a current one making huge transfers go through SCSI using using
> > the sg_table code.  That latter is pretty vital to me since I have to
> > keep the code working, but I don't really have any SCSI cards that can
> > take advantage of it without virtual merging.  As a slight irony, IBM is
> > trying to persuade me that a ppc would be better than a parisc for big
> > endian I/O testing ... so I might just be seeing if I can make virtual
> > merging work on power too.
> 
> All of this is gibberish, we've been over this a few times already
> in this thread.

Really? I must have missed the proposed replacement for the
functionality that we're using then.

> For a dumb I/O card, you advertise SG_ALL capabilities, the IOMMU
> is going to merge things as it would have anyways, and you have
> code in the driver to advance SG entries after each "dumb I/O".

Not that dumb ... they just have a limited number of SG slots.  We
wouldn't want to run them as spoon fed PIO because that really would
kill performance.

> There is zero value to the vmerge code, the real gains are being
> realized already.

There is value to me in my testbed, which I can't achieve any other way
(except by buying different SCSI cards).

As I said, you can compile it out on sparc just fine.  I wish to keep it
running for parisc, so I'll maintain it.  If it ever bit rots out of
parisc like it has done for the other architectures, then feel free to
remove it.

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/