Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758591AbcLOPhh (ORCPT ); Thu, 15 Dec 2016 10:37:37 -0500 Received: from mail-sn1nam01on0102.outbound.protection.outlook.com ([104.47.32.102]:13155 "EHLO NAM01-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755567AbcLOPhg (ORCPT ); Thu, 15 Dec 2016 10:37:36 -0500 From: Dexuan Cui To: Vitaly Kuznetsov , Ming Lei CC: Keith Busch , "linux-block@vger.kernel.org" , Linux Kernel Mailing List , Jens Axboe , Dan Williams , "Martin K. Petersen" , Sagi Grimberg , Long Li , Mike Snitzer , KY Srinivasan , Cathy Avery Subject: RE: [PATCH RFC] block: fix bio merge checks when virt_boundary is set Thread-Topic: [PATCH RFC] block: fix bio merge checks when virt_boundary is set Thread-Index: AQHRmwtRAQJt0GH/M06Tmixhe5Nj46EKf+xw Date: Thu, 15 Dec 2016 14:03:36 +0000 Message-ID: References: <1458055076-2175-1-git-send-email-vkuznets@redhat.com> <87oaae4cej.fsf@vitty.brq.redhat.com> <20160316223804.GA6217@localhost.lm.intel.com> <87egb94agz.fsf@vitty.brq.redhat.com> <20160317163946.GC6217@localhost.lm.intel.com> <87shyg1jdx.fsf@vitty.brq.redhat.com> In-Reply-To: <87shyg1jdx.fsf@vitty.brq.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=decui@microsoft.com; x-originating-ip: [2404:f801:9000:19::259] x-ms-office365-filtering-correlation-id: 4135288e-464a-4e2f-b5d3-08d424f32a1e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR03MB2495; x-microsoft-exchange-diagnostics: 1;MWHPR03MB2495;7:WKHNu3IUfXitHA30Jbw58DpB1VPeNif60FDWeSkzGGUlyHcyzI9M1tkGnFeHqJ+4wCKcBBBDN9MMyw7c7isbhe0ix4GSuNMWWnD97lPK+kDbRv6mFpqgcTRWXIIFP5hQiSaCE+mmqBBU+mPuut9xKRsjNYDBR5+vu9eAFwLQp5ETwVyySqSgQskpAvu/RLczyukH+I7qmdMmdjlx6WZLonL2UGRImVpuyuUaCP6q9JQOpHBzrBWtyYuyV09XaYafPTenzTPyz5E+qFGUjTFSiR/rh4n146qZRzONgqlwPINvlt2FaEaSk5c7nvQAuVkwWTz2v2g0KKWoRTjbZ54vR76Sb8P+0a3zRfLb8gki0iMJ1CHfWI1KHKwPyAb8BCnZxvfsJ+kYrEHHoLbQGWsYHuxEVwowanr7+Pr+vTEpMvAwXO6AWxf5687Yw8EVboKaNaJcd+Y77bHYlPRIjYQXSUEle21x8vBTMoCVrgt2ypE= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(84791874153150)(146099531331640)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(20161123560025)(6072148)(6047074);SRVR:MWHPR03MB2495;BCL:0;PCL:0;RULEID:;SRVR:MWHPR03MB2495; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(209900001)(377454003)(24454002)(189002)(199003)(51694002)(93886004)(106116001)(33656002)(99286002)(189998001)(39060400001)(74316002)(105586002)(3660700001)(2900100001)(8990500004)(3280700002)(10290500002)(76176999)(25786008)(92566002)(5005710100001)(50986999)(54356999)(5890100001)(5001770100001)(122556002)(10090500001)(97736004)(4326007)(2906002)(102836003)(76576001)(86612001)(575784001)(101416001)(68736007)(2950100002)(7696004)(229853002)(15395725005)(7416002)(81156014)(6506006)(38730400001)(6116002)(305945005)(7736002)(77096006)(9686002)(8676002)(81166006)(8936002)(106356001)(6436002)(5660300001)(86362001)(6606295002);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR03MB2495;H:MWHPR03MB2669.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 14:03:36.4948 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB2495 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uBFFbmZX020276 Content-Length: 4090 Lines: 105 > From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel- > owner@vger.kernel.org] On Behalf Of Vitaly Kuznetsov > Sent: Wednesday, April 20, 2016 21:48 > To: Ming Lei > Cc: Keith Busch ; linux-block@vger.kernel.org; Linux > Kernel Mailing List ; Jens Axboe > ; Dan Williams ; Martin K. > Petersen ; Sagi Grimberg > ; Mike Snitzer ; KY Srinivasan > ; Cathy Avery > Subject: Re: [PATCH RFC] block: fix bio merge checks when virt_boundary is set > > Ming Lei writes: > > > On Fri, Mar 18, 2016 at 10:59 AM, Ming Lei wrote: > >> On Fri, Mar 18, 2016 at 12:39 AM, Keith Busch > wrote: > >>> On Thu, Mar 17, 2016 at 12:20:28PM +0100, Vitaly Kuznetsov wrote: > >>>> Keith Busch writes: > >>>> > been combined. In any case, I think you can get what you're after just > >>>> > by moving the gap check after BIOVEC_PHYS_MERGABLE. Does the > following > >>>> > look ok to you? > >>>> > > >>>> > >>>> Thanks, it does. > >>> > >>> Cool, thanks for confirming. > >>> > >>>> Will you send it or would you like me to do that with your Suggested-by? > >>> > >>> I'm not confident yet this doesn't break anything, particularly since > >>> we moved the gap check after the length check. Just wanted to confirm > >>> the concept addressed your concern, but still need to take a closer look > >>> and test before submitting. > >> > >> IMO, the change on blk_bio_segment_split() is correct, because actually it > >> is a sg gap and the check should have been done between segments > >> instead of bvecs. So it is reasonable to move the check just before populating > >> a new segment. > > > > Thinking of the 1st part change further, looks it is just correct in concept, > > but wrong from current implementation. Because of bios/reqs merge, > > blk_rq_map_sg() may end one segment in any bvec in theroy, so I guess > > that is why each non-1st bvec need the check to make sure no sg gap. > > Looks a very crazy limit, :-) > > > >> > >> But for the 2nd change in bio_will_gap(), which should fix Vitaly's problem, I > >> am still not sure if it is completely correct. bio_will_gap() is used > >> to check if two > >> bios may be merged. Suppose two bios are continues physically, the last bvec > >> in 1st bio and the first bvec in 2nd bio might not be in one same segment > >> because of segment size limit. > > > > How about the attached patch? > > > > I just wanted to revive the discussion as the issue persists. I > re-tested your patch against 4.6-rc4 and it efficiently solves the > issue. > > pre-patch: > # time mkfs.ntfs /dev/sdb1 > Cluster size has been automatically set to 4096 bytes. > Initializing device with zeroes: 100% - Done. > Creating NTFS volume structures. > mkntfs completed successfully. Have a nice day. > > real8m10.977s > user0m0.115s > sys0m12.672s > > post-patch: > # time mkfs.ntfs /dev/sdb1 > Cluster size has been automatically set to 4096 bytes. > Initializing device with zeroes: 100% - Done. > Creating NTFS volume structures. > mkntfs completed successfully. Have a nice day. > > real0m42.430s > user0m0.171s > sys0m7.675s > > Will you send this patch? Please let me know if I can further > assist. Thanks! > > -- > Vitaly Hi, I'm reviving the thread because I'm suffering from exactly the same issue. This is the thread I created today: "Big I/O requests are split into small ones due to unaligned ext4 partition boundary?" http://marc.info/?t=148180346100002&r=1&w=2 Ming's patch can fix this issue for me. Stable 4.4 and later are affected too. I didn't check 4.3.x kernels, but for Linux guest on Hyper-V, any kernel with the patch "storvsc: get rid of bounce buffer" https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=81988a0e6b031bc80da15257201810ddcf989e64 should be affected. Thanks, -- Dexuan