Date: Sat, 17 Oct 2015 15:18:24 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Warner Losh <imp@bsdimp.com> Cc: Hans Petter Selasky <hp@selasky.org>, Bruce Evans <brde@optusnet.com.au>, Warner Losh <imp@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r289405 - head/sys/ufs/ffs Message-ID: <20151017135131.T1240@besplex.bde.org> In-Reply-To: <C670A059-B35F-41F3-907A-F0937320CA6D@bsdimp.com> References: <201510160306.t9G3622O049128@repo.freebsd.org> <20151016151349.W1280@besplex.bde.org> <5620B15C.8090104@selasky.org> <C670A059-B35F-41F3-907A-F0937320CA6D@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Oct 2015, Warner Losh wrote: >> On Oct 16, 2015, at 2:12 AM, Hans Petter Selasky <hp@selasky.org> wrote: >> >> On 10/16/15 08:21, Bruce Evans wrote: >>> In addition, making the file contiguous in LBA space doesn't >>> improve the access times from flash devices because they have no seek >>> time. >> >> This is not exactly true, like Bruce pointed out too. Maybe there should= be a check, that if the block is too small reallocate it, else leave it fo= r the sake of the flash. Doing 1K accesses versus 64K accesses will typical= ly show up in the performance benchmark regardless of how fast the underlyi= ng medium is. > > But that=92s not what this does. It isn=92t the defrag code that takes th= e 2-8k fragments and squashes them into 16-64k block size for the device. T= his takes the larger blocks and makes sure they are next to each other. Thi= s takes large contiguous space (like 2MB) and puts as much as possible in a= cylinder group. That=92s totally useless on a flash drive. > > Since the sizes of the blocks are so large, moving them won=92t change an= y benchmarks. Not true. First, the fragment size is actually 512-4K and the block size is 4K-64K and the block size is that of ffs, not of the device (but the ffs size should be chosen to be a multiple of the device size). ffs_doreallocblks() doesn't take large (2MB) blocks and put them in in a cylinder group. It takes not very large (4K-64K) ffs blocks and tries to make them contiguous. Sometimes this gives large (2MB) contiguous sets of blocks). Cylinder groups are irrelevant except that contiguity is impossible across them. The pessimization that I was talking about was expanding the number of i/o's by a large (anything more than 1%) factor by not grouping ffs blocks. I know too much about this from benchmarking and fixing the 10-20% performance loss in soft updates for _reading_ of medium-size files from pessimizal block allocation. The loss was larger for soft updates than for other cases because ffs used its delayed allocation to perfectly pessimize the location of the indirect block. 10%-20% is for files in /usr/src with an ffs block size smaller than its current default of 32K, on a not very fast hard disks. Most of these files don't need an indirect block when the ffs block size is 32K or even 16K. It is surprising that the effect is so large when the block size is even 16K. Then only files larger than 192K need an indirect block. The size of the effect also depends on the amount of caching in disks. With none, any seek kills performance by much more than 10-20%. With some, small seeks are almost free. They just take another i/o to access the disk's cache provided the disk does good read-ahead. The bug seems to be that ffs_doreallocblks() does trimming for _all_ blocks that it looks at although most of them were just written with a delayed write and never reached the disk. Even the extra i/o's for this are not good. Hopefully the disk does nothing for trims on unwritten blocks. Bruce From owner-svn-src-head@freebsd.org Sat Oct 17 04:31:01 2015 Return-Path: <owner-svn-src-head@freebsd.org> Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B69CA16F29; Sat, 17 Oct 2015 04:31:01 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B39515B8; Sat, 17 Oct 2015 04:31:01 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacfv9 with SMTP id fv9so40161173pac.3; Fri, 16 Oct 2015 21:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5P4Kxjkxmx7CThSy0jm4cvPCnjdXJ7mT5ZH6t2xJuHk=; b=PEhNYn+/ZyB3Kpb/XnbgpNEmKAMnBVnBjYT9BfrYiAVdVCu9/L2ML/9P3vx3RX/W77 ES/dijga84l2ZSW6FHWoxYeczkevPUJwwnYsV4WQGXQeNqkbooF25wXxoaKrXEAjqoSI ZyRzULqPH4j/E970BOVKWZEEuUTkbDv7AkHprYuUhy6di9LHQWEWByW6T6lIngFQAJF6 kT39pj2p3kN0FQ92fnAjQzg03G8hVtn+nIxqX3YMhTwYjMvRcZDc/Ef2ecInM9/NjIhs tEgus1Pe0wgltbcUqqaMWgvsr0GflUOXtzMR78ZwjLSlBAxkbpFpKoa9ylSPRWkJuAHL WVTw== X-Received: by 10.66.248.10 with SMTP id yi10mr21057330pac.6.1445056260687; Fri, 16 Oct 2015 21:31:00 -0700 (PDT) Received: from [192.168.20.7] (c-24-16-212-205.hsd1.wa.comcast.net. [24.16.212.205]) by smtp.gmail.com with ESMTPSA id j16sm23972835pbq.23.2015.10.16.21.30.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Oct 2015 21:31:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: svn commit: r289253 - head/share/mk From: NGie Cooper <yaneurabeya@gmail.com> In-Reply-To: <561EB815.6050600@FreeBSD.org> Date: Fri, 16 Oct 2015 21:30:59 -0700 Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Content-Transfer-Encoding: quoted-printable Message-Id: <E5A73D09-5F74-47E9-A0A3-28C6EDE10D21@gmail.com> References: <201510131911.t9DJBMTc034025@repo.freebsd.org> <FC271427-286A-4417-8DDB-5328F303B1F1@gmail.com> <561D7549.2070202@FreeBSD.org> <CAGHfRMBQWZBVqSEQZG_roG-mcibn=Dm6y6QFeW=D9-5yYMNQxQ@mail.gmail.com> <561D8B38.7030202@FreeBSD.org> <CAGHfRMDoEp=DCQ9=DrwEtLyo8Y-VqF31Yd2J5FwZ+ch1_BUvWg@mail.gmail.com> <561EB815.6050600@FreeBSD.org> To: Bryan Drewery <bdrewery@FreeBSD.org> X-Mailer: Apple Mail (2.2104) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>; List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 17 Oct 2015 04:31:01 -0000 > On Oct 14, 2015, at 13:16, Bryan Drewery <bdrewery@FreeBSD.org> wrote: ... > I think what is being seen here is because I removed 'cleanobj' from > bsd.progs.mk (in r288201) to let bsd.obj.mk handle it. It sometimes > recurses clean when needed. If there's an obj dir 'cleanobj' will just > remove that and avoid 'clean'. >=20 > For example (without bsd.progs.mk) >=20 > ~/svn/clean2/usr.bin/vi # make obj > /usr/obj/root/svn/clean2/usr.bin/vi created for = /root/svn/clean2/usr.bin/vi > =3D=3D=3D> catalog (obj) > /usr/obj/root/svn/clean2/usr.bin/vi/catalog created for > /root/svn/clean2/usr.bin/vi/catalog >=20 >=20 > ~/svn/clean2/usr.bin/vi # make cleanobj > =3D=3D=3D> catalog (cleanobj) > rm -f dump dutch english french german polish ru_RU.KOI8-R spanish > swedish uk_UA.KOI8-U zh_CN.GB2312 dutch.UTF-8 french.UTF-8 = german.UTF-8 > polish.UTF-8 spanish.UTF-8 swedish.UTF-8 zh_CN.UTF-8 ru_RU.UTF-8 > uk_UA.UTF-8 english.base *.check __ck1 __ck2 >=20 > Next call finds no obj dir and tries cleaning in local dirs: >=20 > ~/svn/clean2/usr.bin/vi # make cleanobj > rm -f nex nvi nvi.full nvi.debug cl_funcs.o cl_main.o cl_read.o > cl_screen.o cl_term.o conv.o cut.o delete.o encoding.o exf.o key.o > line.o log.o main.o mark.o msg.o options.o options_f.o put.o recover.o > screen.o search.o seq.o util.o ex.o ex_abbrev.o ex_append.o ex_args.o > ex_argv.o ex_at.o ex_bang.o ex_cd.o ex_cmd.o ex_cscope.o ex_delete.o > ex_display.o ex_edit.o ex_equal.o ex_file.o ex_filter.o ex_global.o > ex_init.o ex_join.o ex_map.o ex_mark.o ex_mkexrc.o ex_move.o ex_open.o > ex_preserve.o ex_print.o ex_put.o ex_quit.o ex_read.o ex_screen.o > ex_script.o ex_set.o ex_shell.o ex_shift.o ex_source.o ex_stop.o > ex_subst.o ex_tag.o ex_txt.o ex_undo.o ex_usage.o ex_util.o = ex_version.o > ex_visual.o ex_write.o ex_yank.o ex_z.o getc.o v_at.o v_ch.o v_cmd.o > v_delete.o v_ex.o v_increment.o v_init.o v_itxt.o v_left.o v_mark.o > v_match.o v_paragraph.o v_put.o v_redraw.o v_replace.o v_right.o > v_screen.o v_scroll.o v_search.o v_section.o v_sentence.o v_status.o > v_txt.o v_ulcase.o v_undo.o v_util.o v_word.o v_xchar.o v_yank.o v_z.o > v_zexit.o vi.o vs_line.o vs_msg.o vs_refresh.o vs_relative.o vs_smap.o > vs_split.o regcomp.o regerror.o regexec.o regfree.o vi.1.gz = vi.1.cat.gz > =3D=3D=3D> catalog (clean) > rm -f dump dutch english french german polish ru_RU.KOI8-R spanish > swedish uk_UA.KOI8-U zh_CN.GB2312 dutch.UTF-8 french.UTF-8 = german.UTF-8 > polish.UTF-8 spanish.UTF-8 swedish.UTF-8 zh_CN.UTF-8 ru_RU.UTF-8 > uk_UA.UTF-8 english.base *.check __ck1 __ck2 > rm -f .depend tags > =3D=3D=3D> catalog (cleandepend) > =3D=3D=3D> catalog (cleanobj) > rm -f dump dutch english french german polish ru_RU.KOI8-R spanish > swedish uk_UA.KOI8-U zh_CN.GB2312 dutch.UTF-8 french.UTF-8 = german.UTF-8 > polish.UTF-8 spanish.UTF-8 swedish.UTF-8 zh_CN.UTF-8 ru_RU.UTF-8 > uk_UA.UTF-8 english.base *.check __ck1 __ck2 >=20 >=20 > Similar behavior will happen with bsd.progs.mk usage now. 'cleandir' > also has this flip-flopping behavior. That could be a part of it. Part of the other unintuitive legacy = behavior for make cleandir is that you have to call it twice in order = for it to completely invoke all of the clean targets that its dependent = on: $ uname -a FreeBSD fbsd11 11.0-CURRENT FreeBSD 11.0-CURRENT #6 = r288943+b94810a(isilon-atf): Tue Oct 6 14:54:34 PDT 2015 = ngie@fbsd11:/usr/obj/usr/src/git/sys/GENERIC-NODEBUG amd64 $ make cleandir (cd /usr/src/svn/tests/sys/posixshm && DEPENDFILE=3D.depend.posixshm_test= make -f /usr/src/svn/tests/sys/posixshm/Makefile _RECURSING_PROGS=3D = SUBDIR=3D PROG=3Dposixshm_test cleandir) rm -f posixshm_test posixshm_test.o rm -f .depend.posixshm_test GPATH GRTAGS GSYMS GTAGS [ngie@fbsd11 /usr/src/svn/tests/sys/posixshm]$ make cleandir (cd /usr/src/svn/tests/sys/posixshm && DEPENDFILE=3D.depend.posixshm_test= make -f Makefile _RECURSING_PROGS=3D SUBDIR=3D PROG=3Dposixshm_test = clean) rm -f posixshm_test posixshm_test.o rm -f Kyuafile.auto Kyuafile.auto.tmp (cd /usr/src/svn/tests/sys/posixshm && DEPENDFILE=3D.depend.posixshm_test= make -f Makefile _RECURSING_PROGS=3D SUBDIR=3D PROG=3Dposixshm_test = cleandepend) rm -f .depend.posixshm_test GPATH GRTAGS GSYMS GTAGS (cd /usr/src/svn/tests/sys/posixshm && DEPENDFILE=3D.depend.posixshm_test= make -f Makefile _RECURSING_PROGS=3D SUBDIR=3D PROG=3Dposixshm_test = cleandir) rm -f posixshm_test posixshm_test.o rm -f .depend.posixshm_test GPATH GRTAGS GSYMS GTAGS This might be some of what you were observing above. It looks better now = after the last few days, but it was definitely less functional on head = between the 12th and now on head. Thanks! -NGie=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151017135131.T1240>