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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.64.0807241232040.9412@devserv.devel.redhat.com>
Date:	Thu, 24 Jul 2008 12:34:31 -0400 (EDT)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	David Miller <davem@...emloft.net>, 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 Thu, 24 Jul 2008, James Bottomley wrote:

> On Thu, 2008-07-24 at 11:07 -0400, Mikulas Patocka wrote:
> > So try to #define BIO_VMERGE_BOUNDARY 0 for Pa-Risc and tell us what 
> > performance degradation do you see (and what driver do you use and what is 
> > the I/O pattern).
> > 
> > If you show something specific, we can consider that --- but you haven't 
> > yet told us anything, except generic talk.
> 
> You keep ignoring inconvenient facts.  For about the third time:
> 
> I run a test bed for sg_tables (large chaining of requests).  This runs
> on parisc using virtual merging (has to because the final physical table
> size can't go over the sg list of the SCSI card).  If I turn off virtual
> merging I can no longer test sg_tables in vanilla kernels.
> 
> James

What sg_tables test do you mean? What does the test do? Why couldn't you 
run the test if BIO_VMERGE_BOUNDARY is 0? Normal I/O obviously can work 
with BIO_VMERGE_BOUNDARY 0, the kernel will just send more smaller 
requests.

Mikulas
--
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/