From owner-svn-src-all@FreeBSD.ORG Tue Nov 5 10:13:43 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 705EDA9A; Tue, 5 Nov 2013 10:13:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6A22B3F; Tue, 5 Nov 2013 10:13:41 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA02001; Tue, 05 Nov 2013 12:13:40 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Vdddj-000AUb-Vd; Tue, 05 Nov 2013 12:13:40 +0200 Message-ID: <5278C496.4000002@FreeBSD.org> Date: Tue, 05 Nov 2013 12:12:38 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Xin LI , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r256132 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs References: <201310080138.r981cPcT048197@svn.freebsd.org> In-Reply-To: <201310080138.r981cPcT048197@svn.freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 10:13:43 -0000 on 08/10/2013 04:38 Xin LI said the following: > Author: delphij > Date: Tue Oct 8 01:38:24 2013 > New Revision: 256132 > URL: http://svnweb.freebsd.org/changeset/base/256132 > > Log: > Improve lzjb decompress performance by reorganizing the code > to tighten the copy loop. > > Submitted by: Denis Ahrens > MFC after: 2 weeks > Approved by: re (gjb) > > Modified: > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lzjb.c > > Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lzjb.c > ============================================================================== > --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lzjb.c Mon Oct 7 22:30:03 2013 (r256131) > +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lzjb.c Tue Oct 8 01:38:24 2013 (r256132) > @@ -117,7 +117,9 @@ lzjb_decompress(void *s_start, void *d_s > src += 2; > if ((cpy = dst - offset) < (uchar_t *)d_start) > return (-1); > - while (--mlen >= 0 && dst < d_end) > + if (mlen > (d_end - dst)) > + mlen = d_end - dst; > + while (--mlen >= 0) > *dst++ = *cpy++; > } else { > *dst++ = *src++; > Intuitively it might seem that this change is indeed an improvement. But given how "not dumb" (not sure if that always amounts to smart) the modern compilers are, has anyone actually measured if this change indeed improves the performance? Judging from the conversations on the ZFS mailing lists this change event hurt performance in some environments. Looks like the upstream is not going to take this change. So does it make any sense for us to make the code more obscure and different from upstream? Unless performance benefits could indeed be demonstrated. -- Andriy Gapon