From owner-svn-src-all@freebsd.org Thu Oct 15 08:15:05 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4B736436DDF; Thu, 15 Oct 2020 08:15:05 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CBhsh1DWVz49lR; Thu, 15 Oct 2020 08:15:04 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: by mail-ej1-f66.google.com with SMTP id a3so2264149ejy.11; Thu, 15 Oct 2020 01:15:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LuaJfgIKpVdI7e2BREzIKyWu16PvMdnlzu7OTxr2NuU=; b=Sm8jSZFBr8HuhBJsGhCkXYu6t19uy+YbN/+GfnSyvalImcxK9lC34MawWHAMdpsKik z93k4teifmmGpOePFxCIEzyeSOLCm0Ap3Jyxj0bFkD978Mmz2XGXWS+aSJo5Gv1rJFZK 5SOQK7tqYWtwDPfylP9CX7JDDoZ5QK5P5lzIhDc7ChhF9eG2yAjttTsvP1kcTD6Uud+M guBejWvRF3hSnA8eAEBq8yfCsogkr8mR/pF+oeP9+WCgqqGTvx672x8ajXFVMT48bP8w oa6ZNjeW7ZYgF9FQMlyL/69J5xiVBK5WnUkaQvfU//e3mQ/7PsU8yXIDLuSvbLowODs+ D2gQ== X-Gm-Message-State: AOAM53344jwLJsjN5ElcOuSWXwDZeAYZ+Kyo46aarn8IuFXGkTRXEGUS FG/+FpbMvsmT237hWjoJmO0pY250bm2hSw== X-Google-Smtp-Source: ABdhPJxyXtBGVISUZrWvGRDbITpSzPgscJYEqCp7HO/syXnVkUv+aU2TxxlBohFclcZhzzegQCSELA== X-Received: by 2002:a17:906:3c03:: with SMTP id h3mr645030ejg.78.1602749702391; Thu, 15 Oct 2020 01:15:02 -0700 (PDT) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com. [209.85.128.53]) by smtp.gmail.com with ESMTPSA id j18sm1002345ejc.111.2020.10.15.01.15.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2020 01:15:02 -0700 (PDT) Received: by mail-wm1-f53.google.com with SMTP id b127so2503226wmb.3; Thu, 15 Oct 2020 01:15:01 -0700 (PDT) X-Received: by 2002:a1c:c28a:: with SMTP id s132mr2667818wmf.67.1602749701737; Thu, 15 Oct 2020 01:15:01 -0700 (PDT) MIME-Version: 1.0 References: <202010141228.09ECSg0D023438@repo.freebsd.org> <463B3544-BF7B-49FF-82EA-ECB5D8FBB17B@gmail.com> In-Reply-To: <463B3544-BF7B-49FF-82EA-ECB5D8FBB17B@gmail.com> From: Alexander Richardson Date: Thu, 15 Oct 2020 09:14:51 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r366697 - head/usr.bin/xinstall To: Enji Cooper Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4CBhsh1DWVz49lR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of arichardsonkde@gmail.com designates 209.85.218.66 as permitted sender) smtp.mailfrom=arichardsonkde@gmail.com X-Spamd-Result: default: False [-2.02 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_NEQ_ENVFROM(0.00)[arichardson@freebsd.org,arichardsonkde@gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.996]; RWL_MAILSPIKE_GOOD(0.00)[209.85.218.66:from]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.32)[-0.323]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.66:from]; NEURAL_HAM_MEDIUM(-0.70)[-0.698]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[arichardson@freebsd.org,arichardsonkde@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; MAILMAN_DEST(0.00)[svn-src-all,svn-src-head] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 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: Thu, 15 Oct 2020 08:15:05 -0000 On Thu, 15 Oct 2020 at 06:59, Enji Cooper wrote: > > > > On Oct 14, 2020, at 5:28 AM, Alex Richardson wrote: > > > > Author: arichardson > > Date: Wed Oct 14 12:28:41 2020 > > New Revision: 366697 > > URL: https://svnweb.freebsd.org/changeset/base/366697 > > > > Log: > > install(1): Avoid unncessary fstatfs() calls and use mmap() based on size > > > > According to git blame the trymmap() function was added in 1996 to skip > > mmap() calls for NFS file systems. However, nowadays mmap() should be > > perfectly safe even on NFS. Importantly, onl ufs and cd9660 file systems > > were whitelisted so we don't use mmap() on ZFS. It also prevents the use > > of mmap() when bootstrapping from macOS/Linux since on those systems the > > trymmap() function was always returning zero due to the missing MFSNAMELEN > > define. > > > > This change keeps the trymmap() function but changes it to check whether > > using mmap() can reduce the number of system calls that are required. > > Using mmap() only reduces the number of system calls if we need multiple read() > > syscalls, i.e. if the file size is > MAXBSIZE. However, mmap() is more expensive > > than read() so this sets the threshold at 4 fewer syscalls. Additionally, for > > larger file size mmap() can significantly increase the number of page faults, > > so avoid it in that case. > > > > It's unclear whether using mmap() is ever faster than a read with an appropriate > > buffer size, but this change at least removes two unnecessary system calls > > for every file that is installed. > > > > Reviewed By: markj > > Differential Revision: https://reviews.freebsd.org/D26041 > > * Has this change been tested out with source filesystems other than UFS/ZFS? Not all filesystems support mmap(2). I've used ext4 and afps, but it doesn't matter since there's a fallback. > * trymmap(..) seems to be less about computing whether or not the filesystem should use mmap(2) after this change, but how it should use mmap(2). Seems like a misnamed function call now. There was always fallback code in case mmap fails: https://github.com/freebsd/freebsd/blob/8349de39d23fc152c3782ee3b9eeab3df4610944/usr.bin/xinstall/xinstall.c#L1253 and https://github.com/freebsd/freebsd/blob/8349de39d23fc152c3782ee3b9eeab3df4610944/usr.bin/xinstall/xinstall.c#L1253 so it is really "should I try to use mmap()". Alex