From owner-freebsd-arch@FreeBSD.ORG Tue Dec 16 05:00:58 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEC0DBD4; Tue, 16 Dec 2014 05:00:58 +0000 (UTC) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96516183; Tue, 16 Dec 2014 05:00:58 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id r2so6264611igi.12; Mon, 15 Dec 2014 21:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=HLwcJ1rqAW9U8mm2Ud4VPWMdqJOYD7blWWtbl+vpXJM=; b=S+yxhL485cAtW7nFWUwUSM/sH7iSCX1DqCwRFIfti8I1ttK6hC/VfPBa78rtMeOExo 83Zk6KFzujwDWpYbnno75LXbbZxM7183M1wrGCLSvseZPewGAugDsJS0ukStkcRBPzRQ DrNoIV7fgMqvg+Fa3VayawBjRMEMlzWw3f+Vi6I/V2VsrGf2R90F/H02g6/o1R5PFHpK usuAUymAWcfu4O+eRQThNteGMdPbnk8cUM3iHrSu/CqTNXzwyXmNvvwvIcgD0xVDPBVR KnwMbnAk4tUOS+vAKB6HaIagfVfO3icF90NVH2fDLy2hGKWV3/vyzhiM8GxjHKWboyWB TTEg== X-Received: by 10.42.129.140 with SMTP id q12mr29942582ics.68.1418706051734; Mon, 15 Dec 2014 21:00:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.175.4 with HTTP; Mon, 15 Dec 2014 21:00:21 -0800 (PST) From: Jia-Shiun Li Date: Tue, 16 Dec 2014 13:00:21 +0800 Message-ID: Subject: _bootstrap-tools parallel build (was: Re: CFR, CFT: Fine-grained SUBDIR dependencies for parallel builds To: Ian Lepore Content-Type: multipart/mixed; boundary=20cf3011e059414030050a4e3ec9 Cc: freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 05:00:58 -0000 --20cf3011e059414030050a4e3ec9 Content-Type: text/plain; charset=UTF-8 On Sat, May 31, 2014 at 10:04 PM, Ian Lepore wrote: > > The parallelism in the bootstrap stuff in Makefile.inc1 is done with a > different-but-similar mechanism, and it would be nice to fix that to > just use bsd.subdir.mk instead of almost-duplicating it inline. That's > on a longer-term to-do list for me. > Hi Ian & all, I did it manually for _bootstrap-tools anyway. Patches attached. It reduces 'make -j24 _botostrap-tools' time from ~55 sec. to ~25 sec. on a 12C IVB-EP. It scales more linearly in comparison to single-job ~250 sec on the same machine. Main blockers were tblgen & groff. On -j4 it reduces time from ~82 sec. to ~60 sec. too. It passed 'make -j24 universe' except the seemingly broken i386 kernels. Any comments? -Jia-Shiun --20cf3011e059414030050a4e3ec9 Content-Type: application/octet-stream; name="bootstrap.patch" Content-Disposition: attachment; filename="bootstrap.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i3qsoqf70 SW5kZXg6IE1ha2VmaWxlLmluYzEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gTWFrZWZpbGUuaW5jMQkocmV2aXNp b24gMjc1Njk5KQorKysgTWFrZWZpbGUuaW5jMQkod29ya2luZyBjb3B5KQpAQCAtMTMxMywxMSAr MTMxMyw3IEBACiAJdXNyLmJpbi9jb21waWxlX2V0CiAuZW5kaWYKIAotIwlQbGVhc2UgZG9jdW1l bnQgKGFkZCBjb21tZW50KSB3aHkgc29tZXRoaW5nIGlzIGluICdib290c3RyYXAtdG9vbHMnLgot IwlUcnkgdG8gYm91bmQgdGhlIGJ1aWxkaW5nIG9mIHRoZSBib290c3RyYXAtdG9vbCB0byBqdXN0 IHRoZQotIwlGcmVlQlNEIHZlcnNpb25zIHRoYXQgbmVlZCB0aGUgdG9vbCBidWlsdCBhdCB0aGlz IHN0YWdlIG9mIHRoZSBidWlsZC4KLWJvb3RzdHJhcC10b29sczogLk1BS0UKLS5mb3IgX3Rvb2wg aW4gXAorQlRfRElSUz0gXAogICAgICR7X2NsYW5nX3RibGdlbn0gXAogICAgICR7X2tlcmJlcm9z NV9ib290c3RyYXBfdG9vbHN9IFwKICAgICAke19kdHJhY2VfdG9vbHN9IFwKQEAgLTEzNDAsMTUg KzEzMzYsNDAgQEAKICAgICB1c3Iuc2Jpbi9jb25maWcgXAogICAgICR7X2NydW5jaH0gXAogICAg ICR7X25tdHJlZX0gXAotICAgICR7X3Z0Zm9udGN2dH0KLQkke18rX31AJHtFQ0hPRElSfSAiPT09 PiAke190b29sfSAob2JqLGRlcGVuZCxhbGwsaW5zdGFsbCkiOyBcCi0JCWNkICR7LkNVUkRJUn0v JHtfdG9vbH0gJiYgXAotCQkke01BS0V9IERJUlBSRlg9JHtfdG9vbH0vIG9iaiAmJiBcCi0JCSR7 TUFLRX0gRElSUFJGWD0ke190b29sfS8gZGVwZW5kICYmIFwKLQkJJHtNQUtFfSBESVJQUkZYPSR7 X3Rvb2x9LyBhbGwgJiYgXAotCQkke01BS0V9IERJUlBSRlg9JHtfdG9vbH0vIERFU1RESVI9JHtN QUtFT0JKRElSUFJFRklYfS9sZWdhY3kgaW5zdGFsbAorICAgICR7X3Z0Zm9udGN2dH0gXAorCisu Zm9yIFggaW4gJHtCVF9ESVJTfQorIyBHZW5lcmF0ZSBydWxlcworJHtYfTogLlBIT05ZCisJJHtf K199QCR7RUNIT0RJUn0gIj09PT4gJHtYfSAob2JqLGRlcGVuZCxhbGwsaW5zdGFsbCkiOyBcCisJ CWNkICR7LkNVUkRJUn0vJHtYfSAmJiBcCisJCSR7TUFLRX0gRElSUFJGWD0ke1h9LyBvYmogJiYg XAorCQkke01BS0V9IERJUlBSRlg9JHtYfS8gZGVwZW5kICYmIFwKKwkJJHtNQUtFfSBESVJQUkZY PSR7WH0vIGFsbCAmJiBcCisJCSR7TUFLRX0gRElSUFJGWD0ke1h9LyBERVNURElSPSR7TUFLRU9C SkRJUlBSRUZJWH0vbGVnYWN5IGluc3RhbGwKIC5lbmRmb3IKIAorIyAke19jbGFuZ190YmxnZW59 IGRlcGVuZGVuY2llcwordXNyLmJpbi9jbGFuZy90YmxnZW46IGxpYi9jbGFuZy9saWJsbHZtdGFi bGVnZW4gbGliL2NsYW5nL2xpYmxsdm1zdXBwb3J0Cit1c3IuYmluL2NsYW5nL2NsYW5nLXRibGdl bjogbGliL2NsYW5nL2xpYmxsdm10YWJsZWdlbiBsaWIvY2xhbmcvbGlibGx2bXN1cHBvcnQKKwor IyAke19rZXJiZXJvczVfYm9vdHN0cmFwX3Rvb2xzfSBkZXBlbmRlbmNpZXMKK2tlcmJlcm9zNS90 b29scy9zbGM6IGtlcmJlcm9zNS9saWIvbGlicm9rZW4KK2tlcmJlcm9zNS90b29scy9hc24xX2Nv bXBpbGU6IGtlcmJlcm9zNS9saWIvbGlicm9rZW4KKworIyBiZWxvdyBkZXBlbmRlbmNpZXMgbm90 IHRlc3RlZCBidXQgcmVwbGljYXRlZCBhcy1pcworIyAke195YWNjfQordXNyLmJpbi95YWNjOiBs aWIvbGlieQorIyAke19tNH0KK3Vzci5iaW4vbTQ6IGxpYi9saWJvaGFzaAorIyAke19ubXRyZWV9 Cit1c3Iuc2Jpbi9ubXRyZWU6IGxpYi9saWJuZXRic2QKKworIwlQbGVhc2UgZG9jdW1lbnQgKGFk ZCBjb21tZW50KSB3aHkgc29tZXRoaW5nIGlzIGluICdib290c3RyYXAtdG9vbHMnLgorIwlUcnkg dG8gYm91bmQgdGhlIGJ1aWxkaW5nIG9mIHRoZSBib290c3RyYXAtdG9vbCB0byBqdXN0IHRoZQor IwlGcmVlQlNEIHZlcnNpb25zIHRoYXQgbmVlZCB0aGUgdG9vbCBidWlsdCBhdCB0aGlzIHN0YWdl IG9mIHRoZSBidWlsZC4KK2Jvb3RzdHJhcC10b29sczogJHtCVF9ESVJTfQorCiAjCiAjIGJ1aWxk LXRvb2xzOiBCdWlsZCBzcGVjaWFsIHB1cnBvc2UgYnVpbGQgdG9vbHMKICMKSW5kZXg6IGdudS91 c3IuYmluL2dyb2ZmL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGdudS91c3IuYmluL2dyb2ZmL01h a2VmaWxlCShyZXZpc2lvbiAyNzU2OTkpCisrKyBnbnUvdXNyLmJpbi9ncm9mZi9NYWtlZmlsZQko d29ya2luZyBjb3B5KQpAQCAtMiw0ICsyLDYgQEAKIAogU1VCRElSPQkJY29udHJpYiBkb2MgZm9u dCBtYW4gc3JjIHRtYWMKIAorU1VCRElSX1BBUkFMTEVMPQorCiAuaW5jbHVkZSA8YnNkLnN1YmRp ci5taz4KSW5kZXg6IGdudS91c3IuYmluL2dyb2ZmL3NyYy9NYWtlZmlsZQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBnbnUvdXNyLmJpbi9ncm9mZi9zcmMvTWFrZWZpbGUJKHJldmlzaW9uIDI3NTY5OSkKKysrIGdu dS91c3IuYmluL2dyb2ZmL3NyYy9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMiw0ICsyLDEw IEBACiAKIFNVQkRJUj0JCWxpYnMgZGV2aWNlcyBwcmVwcm9jIHJvZmYgdXRpbHMKIAorU1VCRElS X1BBUkFMTEVMPQorU1VCRElSX0RFUEVORF9kZXZpY2VzPSBsaWJzCitTVUJESVJfREVQRU5EX3By ZXByb2M9IGxpYnMKK1NVQkRJUl9ERVBFTkRfcm9mZj0gbGlicworU1VCRElSX0RFUEVORF91dGls cz0gbGlicworCiAuaW5jbHVkZSA8YnNkLnN1YmRpci5taz4KSW5kZXg6IGdudS91c3IuYmluL2dy b2ZmL3NyYy9kZXZpY2VzL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGdudS91c3IuYmluL2dyb2Zm L3NyYy9kZXZpY2VzL01ha2VmaWxlCShyZXZpc2lvbiAyNzU2OTkpCisrKyBnbnUvdXNyLmJpbi9n cm9mZi9zcmMvZGV2aWNlcy9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMiw0ICsyLDYgQEAK IAogU1VCRElSPQkJZ3JvZHZpIGdyb2h0bWwgZ3JvbGJwIGdyb2xqNCBncm9wcyBncm90dHkKIAor U1VCRElSX1BBUkFMTEVMPQorCiAuaW5jbHVkZSA8YnNkLnN1YmRpci5taz4KSW5kZXg6IGdudS91 c3IuYmluL2dyb2ZmL3NyYy9wcmVwcm9jL01ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGdudS91c3Iu YmluL2dyb2ZmL3NyYy9wcmVwcm9jL01ha2VmaWxlCShyZXZpc2lvbiAyNzU2OTkpCisrKyBnbnUv dXNyLmJpbi9ncm9mZi9zcmMvcHJlcHJvYy9NYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMiw0 ICsyLDYgQEAKIAogU1VCRElSPQkJZXFuIGdybiBodG1sIHBpYyByZWZlciBzb2VsaW0gdGJsCiAK K1NVQkRJUl9QQVJBTExFTD0KKwogLmluY2x1ZGUgPGJzZC5zdWJkaXIubWs+CkluZGV4OiBnbnUv dXNyLmJpbi9ncm9mZi9zcmMvcm9mZi9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBnbnUvdXNyLmJp bi9ncm9mZi9zcmMvcm9mZi9NYWtlZmlsZQkocmV2aXNpb24gMjc1Njk5KQorKysgZ251L3Vzci5i aW4vZ3JvZmYvc3JjL3JvZmYvTWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTIsNCArMiw2IEBA CiAKIFNVQkRJUj0JCWdyb2ZmIGdyb2cgbnJvZmYgcHNyb2ZmIHRyb2ZmCiAKK1NVQkRJUl9QQVJB TExFTD0KKwogLmluY2x1ZGUgPGJzZC5zdWJkaXIubWs+CkluZGV4OiBnbnUvdXNyLmJpbi9ncm9m Zi9zcmMvdXRpbHMvTWFrZWZpbGUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZ251L3Vzci5iaW4vZ3JvZmYvc3Jj L3V0aWxzL01ha2VmaWxlCShyZXZpc2lvbiAyNzU2OTkpCisrKyBnbnUvdXNyLmJpbi9ncm9mZi9z cmMvdXRpbHMvTWFrZWZpbGUJKHdvcmtpbmcgY29weSkKQEAgLTIsNCArMiw2IEBACiAKIFNVQkRJ Uj0JCWFkZGZ0aW5mbyBhZm10b2RpdCBocGZ0b2RpdCBpbmR4YmliIGxrYmliIGxvb2tiaWIgcGZi dG9wcyB0Zm10b2RpdAogCitTVUJESVJfUEFSQUxMRUw9CisKIC5pbmNsdWRlIDxic2Quc3ViZGly Lm1rPgo= --20cf3011e059414030050a4e3ec9-- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 16 18:48:45 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F9D93C1 for ; Tue, 16 Dec 2014 18:48:45 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BFE6B07 for ; Tue, 16 Dec 2014 18:48:45 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 33F01B94F for ; Tue, 16 Dec 2014 13:48:44 -0500 (EST) From: John Baldwin To: arch@freebsd.org Subject: Change default VFS timestamp precision? Date: Tue, 16 Dec 2014 13:48:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201412161348.41219.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Dec 2014 13:48:44 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:48:45 -0000 We still ship with vfs.timestamp_precision=0 by default meaning that VFS timestamps have a granularity of one second. It is not unusual on modern systems for multiple updates to a file or directory to occur within a single second (and thus share the same effective timestamp). This can break things that depend on timestamps to know when something has changed or is stale (such as make(1) or NFS clients). On hardware that has a cheap timecounter, I we should use the most-precise timestamps (vfs.timestamp_precision=3). However, I'm less sure of what to do for other cases such as i386/amd64 when not using TSC, or on other platforms. OTOH, perhaps you aren't doing lots of heavy I/O access on a system with a slow timecounter (or if you are doing heavy I/O, slow timecounter access won't be your bottleneck)? I can think of a few options: 1) Change vfs.timestamp_precision default to 3 for all systems. 2) Only change vfs.timestamp_precision default to 3 for amd64/i386 using an #ifdef. 3) Something else? What do other folks think? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Dec 16 18:56:34 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 539F7526 for ; Tue, 16 Dec 2014 18:56:34 +0000 (UTC) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23ACCBFD for ; Tue, 16 Dec 2014 18:56:34 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id z10so14541281pdj.0 for ; Tue, 16 Dec 2014 10:56:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=2JdBuv3lOkB4duIuqqvLs3SEZaUucwoFHvvxOjDarP4=; b=DiHUjGcGVD66ELO7r5xRvT5l8mLiV3Sq140+Zm8VsDYeaLRID0SdbFhZ9IB0H2BQWX QdHl+dEzLAGz1ZX1KDtlxQMeEtX+0gM3g590SyiNzQzZWxMJcO10Co66DaWiobIfo4yc 23AV7ab3bCRi8goK7//wLbLytWRAEKuRQShTfMYIBWvoZB4qjr6FQBIHeQg6zSGVgpJ9 CFO8zFu/uvhPkacLV9yPr8E9GGHxJch9GY+vkKjLgKTTjN5QdbOjvyQzzAw+USQlVamv BB508QXKsh+ckNxPh9M9km3xw1W9IRFSWZBLkELT5O3EuJ/88sGGMc5ShcNo8n9Ob0pn BTFw== X-Gm-Message-State: ALoCoQlJOuyEn/k0GjbKmREgwpB4SJ7V2gcs1Fh1nYEaDVC072Nj42WgmvP+SuEw7fcKYCP4b4LH X-Received: by 10.68.134.3 with SMTP id pg3mr41933843pbb.84.1418755873251; Tue, 16 Dec 2014 10:51:13 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id uq15sm1721146pab.8.2014.12.16.10.51.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 10:51:12 -0800 (PST) Sender: Warner Losh Subject: Re: Change default VFS timestamp precision? Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_75C1AB44-77FF-4500-9498-506EA83706C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <201412161348.41219.jhb@freebsd.org> Date: Tue, 16 Dec 2014 11:51:09 -0700 Message-Id: <708ECB13-C3A1-46E9-BF29-6F544CC4FDE6@bsdimp.com> References: <201412161348.41219.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1993) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 18:56:34 -0000 --Apple-Mail=_75C1AB44-77FF-4500-9498-506EA83706C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 16, 2014, at 11:48 AM, John Baldwin wrote: >=20 > We still ship with vfs.timestamp_precision=3D0 by default meaning that = VFS > timestamps have a granularity of one second. It is not unusual on = modern > systems for multiple updates to a file or directory to occur within a = single > second (and thus share the same effective timestamp). This can break = things > that depend on timestamps to know when something has changed or is = stale (such > as make(1) or NFS clients). On hardware that has a cheap timecounter, = I we > should use the most-precise timestamps (vfs.timestamp_precision=3D3). = However, > I'm less sure of what to do for other cases such as i386/amd64 when = not using > TSC, or on other platforms. OTOH, perhaps you aren't doing lots of = heavy I/O > access on a system with a slow timecounter (or if you are doing heavy = I/O, > slow timecounter access won't be your bottleneck)? >=20 > I can think of a few options: >=20 > 1) Change vfs.timestamp_precision default to 3 for all systems. >=20 > 2) Only change vfs.timestamp_precision default to 3 for amd64/i386 = using an > #ifdef. >=20 > 3) Something else? >=20 > What do other folks think? (1). If there=E2=80=99s a specific kernel / platform that=E2=80=99s = slow, we can make it an option for those kernels. Warner --Apple-Mail=_75C1AB44-77FF-4500-9498-506EA83706C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkH8eAAoJEGwc0Sh9sBEAAVYP/2Nx/+9TZzzn2gSxQJUgMGCh pxG+gTtbxjJsVOOXHF2TYtZg49d8AadDTFzyqngbmEfapKuxCjF2Vqd5YpUrRl96 KnZADWOOSV0ZdojOPVQ3fJYzHu0pK3SH4x36hDLyO7Zrlh75fCzFH/eO6c3IbGmW ViAOQ7PP1S4BvOPYmGv2yG5UiWyLUbyOjlw/QB4SxgbTnzOwCxqqx8l+bFz1Jccq 3f0+pTuJS3RWCelQ0YZQVBZwgBCh+i3FBosZOUFjYNrtu6vETZa8kfs5i7vkEvMJ gJV2PO8sVaCBrwR3nm57YSDlC6NobwFcK7R9l5f8/h0clBNH1xlsM+/vu19SjHma J8gKoWMWf1ASezuQL8sWHh3hg35ymsGFhmNYLFu3HOnNWM5zKEd6d+b4GR+t324L 0i8QA/p1vfe4DJeBn1mJXmRxdgJAn+VrEJi3iJHg7HJ3TJL93th8d5G3BjFebik7 MO83umZnl+hvL8LrLp/SfK2b5RNo91v8zHedGFMcvc5pdz1jpKVmA+IZOO4Lv1cf rzDX7+q2cfQHptPB5BGjpFQ1F499/WBYvx5fkyzbk02MlEPqGoisFeRN/VN+/ECv +eT/kzISez56c5HuweShzna4JpVeCbEH5XtKIiO8AQU7kJrIWX5cPMsJB4Dk+GWa q3fvu5LRvKzxN1KNDEv/ =AS9o -----END PGP SIGNATURE----- --Apple-Mail=_75C1AB44-77FF-4500-9498-506EA83706C7-- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 16 22:08:15 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C281A6BE for ; Tue, 16 Dec 2014 22:08:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CC28A2D for ; Tue, 16 Dec 2014 22:08:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 366F5B945; Tue, 16 Dec 2014 17:08:14 -0500 (EST) From: John Baldwin To: Warner Losh Subject: Re: Change default VFS timestamp precision? Date: Tue, 16 Dec 2014 14:37:16 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201412161348.41219.jhb@freebsd.org> <708ECB13-C3A1-46E9-BF29-6F544CC4FDE6@bsdimp.com> In-Reply-To: <708ECB13-C3A1-46E9-BF29-6F544CC4FDE6@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201412161437.16767.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 16 Dec 2014 17:08:14 -0500 (EST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 22:08:15 -0000 On Tuesday, December 16, 2014 1:51:09 pm Warner Losh wrote: >=20 > > On Dec 16, 2014, at 11:48 AM, John Baldwin wrote: > >=20 > > We still ship with vfs.timestamp_precision=3D0 by default meaning that = VFS > > timestamps have a granularity of one second. It is not unusual on mode= rn > > systems for multiple updates to a file or directory to occur within a s= ingle > > second (and thus share the same effective timestamp). This can break t= hings > > that depend on timestamps to know when something has changed or is stal= e (such > > as make(1) or NFS clients). On hardware that has a cheap timecounter, = I we > > should use the most-precise timestamps (vfs.timestamp_precision=3D3). = However, > > I'm less sure of what to do for other cases such as i386/amd64 when not= using > > TSC, or on other platforms. OTOH, perhaps you aren't doing lots of hea= vy I/O > > access on a system with a slow timecounter (or if you are doing heavy I= /O, > > slow timecounter access won't be your bottleneck)? > >=20 > > I can think of a few options: > >=20 > > 1) Change vfs.timestamp_precision default to 3 for all systems. > >=20 > > 2) Only change vfs.timestamp_precision default to 3 for amd64/i386 usin= g an > > #ifdef. > >=20 > > 3) Something else? > >=20 > > What do other folks think? >=20 > (1). If there=E2=80=99s a specific kernel / platform that=E2=80=99s slow,= we can make it an option > for those kernels. Mm, so something like: Index: vfs_subr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- vfs_subr.c (revision 275828) +++ vfs_subr.c (working copy) @@ -632,7 +632,11 @@ vfs_getnewfsid(struct mount *mp) */ enum { TSP_SEC, TSP_HZ, TSP_USEC, TSP_NSEC }; =20 +#ifdef VFS_CHEAP_TIMESTAMPS static int timestamp_precision =3D TSP_SEC; +#else +static int timestamp_precision =3D TSP_NSEC; +#endif SYSCTL_INT(_vfs, OID_AUTO, timestamp_precision, CTLFLAG_RW, ×tamp_precision, 0, "File timestamp precision (0: seconds, " "1: sec + ns accurate to 1/HZ, 2: sec + ns truncated to ms, " where VFS_CHEAP_TIMESTAMPS becomes a new kernel config option? (We should also probably make this a loader tunable) =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Dec 16 22:41:37 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E1F4C69 for ; Tue, 16 Dec 2014 22:41:37 +0000 (UTC) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E194CDB8 for ; Tue, 16 Dec 2014 22:41:36 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id et14so15097819pad.3 for ; Tue, 16 Dec 2014 14:41:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=ezXKEG3aynbfd2pkMk+ylQzWigAIWMbCw3x120CwbJE=; b=f1tSYs91+AQqw/u+E+rCmFfdC5avGr2PesylJu/syY9WO9xBiYrGC0ocJchOZKEts1 h4/j8OzIVJpCYAHOAaVcm9As3+W0EstavdtnWDUNUfFwDpbx/8d+U3i8vlslAH69hkLe F5OYIfaO2T1GGeTtiVn/9/sv2YdxbeMk5d3yqw/IlDrjB6hMskA/8U4uNhQOraWzWYvD YvBKBxQmt2G6ucl/pm1sDUlk+tI2rzOd5GKl6XDoFOYs+9dNi6piopC7z1HsuO4ZM7lV wAkmRw1vOWjnT027lc9WpYYiK5YvHV+oO7/udTkJj3zrx3cjEg9ADHHz7EGgVxwtC9gS 2wfg== X-Gm-Message-State: ALoCoQmTbP3IDHmoU+QCKc0Bnw1881vgcpWa5J/p6d3FYq+MUbgSQlReucw2EW4OFP3LTwqd2dSO X-Received: by 10.67.3.165 with SMTP id bx5mr64641294pad.59.1418769695715; Tue, 16 Dec 2014 14:41:35 -0800 (PST) Received: from [10.64.27.55] ([69.53.236.236]) by mx.google.com with ESMTPSA id vz3sm2010106pab.2.2014.12.16.14.41.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 14:41:34 -0800 (PST) Sender: Warner Losh Subject: Re: Change default VFS timestamp precision? Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0ADC3D5A-DF91-4825-ABDA-863E50C35313"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <201412161437.16767.jhb@freebsd.org> Date: Tue, 16 Dec 2014 15:41:32 -0700 Message-Id: <12A1D992-44B8-4FB6-A069-EB7635D54914@bsdimp.com> References: <201412161348.41219.jhb@freebsd.org> <708ECB13-C3A1-46E9-BF29-6F544CC4FDE6@bsdimp.com> <201412161437.16767.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1993) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 22:41:37 -0000 --Apple-Mail=_0ADC3D5A-DF91-4825-ABDA-863E50C35313 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 16, 2014, at 12:37 PM, John Baldwin wrote: >=20 > On Tuesday, December 16, 2014 1:51:09 pm Warner Losh wrote: >>=20 >>> On Dec 16, 2014, at 11:48 AM, John Baldwin wrote: >>>=20 >>> We still ship with vfs.timestamp_precision=3D0 by default meaning = that VFS >>> timestamps have a granularity of one second. It is not unusual on = modern >>> systems for multiple updates to a file or directory to occur within = a single >>> second (and thus share the same effective timestamp). This can = break things >>> that depend on timestamps to know when something has changed or is = stale (such >>> as make(1) or NFS clients). On hardware that has a cheap = timecounter, I we >>> should use the most-precise timestamps (vfs.timestamp_precision=3D3). = However, >>> I'm less sure of what to do for other cases such as i386/amd64 when = not using >>> TSC, or on other platforms. OTOH, perhaps you aren't doing lots of = heavy I/O >>> access on a system with a slow timecounter (or if you are doing = heavy I/O, >>> slow timecounter access won't be your bottleneck)? >>>=20 >>> I can think of a few options: >>>=20 >>> 1) Change vfs.timestamp_precision default to 3 for all systems. >>>=20 >>> 2) Only change vfs.timestamp_precision default to 3 for amd64/i386 = using an >>> #ifdef. >>>=20 >>> 3) Something else? >>>=20 >>> What do other folks think? >>=20 >> (1). If there=E2=80=99s a specific kernel / platform that=E2=80=99s = slow, we can make it an option >> for those kernels. >=20 > Mm, so something like: >=20 > Index: vfs_subr.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- vfs_subr.c (revision 275828) > +++ vfs_subr.c (working copy) > @@ -632,7 +632,11 @@ vfs_getnewfsid(struct mount *mp) > */ > enum { TSP_SEC, TSP_HZ, TSP_USEC, TSP_NSEC }; >=20 > +#ifdef VFS_CHEAP_TIMESTAMPS > static int timestamp_precision =3D TSP_SEC; > +#else > +static int timestamp_precision =3D TSP_NSEC; > +#endif > SYSCTL_INT(_vfs, OID_AUTO, timestamp_precision, CTLFLAG_RW, > ×tamp_precision, 0, "File timestamp precision (0: seconds, " > "1: sec + ns accurate to 1/HZ, 2: sec + ns truncated to ms, " >=20 > where VFS_CHEAP_TIMESTAMPS becomes a new kernel config option? >=20 > (We should also probably make this a loader tunable) Yea, the DEFAULT behavior should be set at compile time, the run-time = behavior should be set by this variable=E2=80=A6. Tunable is good too, = but the sysctl likely will suffice for that given how early the = sysctl.conf file is snarfed. Warner --Apple-Mail=_0ADC3D5A-DF91-4825-ABDA-863E50C35313 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUkLUcAAoJEGwc0Sh9sBEA2KwP/3GIsl+aQjVntSbVtcajeoa+ v/bnG27WqpoUNOu0S6IQYJ0DlKmCPDD4Z19Jq7OpOAEa+53779NOWd3AQYeYp9s1 AlZygZQJ1p7jisQtrCYUOqbvCjZFw7AtQ6n/DqrnsmKr5fOtno0XUEQyN+z/ps/7 TgDoGREgMcjMOWvn1F25rfkTH7eWgD+N+Dzusj7TgLV3cchz5XPEQRHLi+YOK8ab l7umz5AiEFd7CrCOGrA/2BqoXUxlPvbtfL14t2DHmOoy3XDX864r6jKNAy/tGugi 08wJTt9FmibhBZh6FSpYt1IM3d3AHTLO9Dt63EWENsM1xrEZaNEL2EKS91Hs8+3Y UEsVYKF0hltJm17QX2InLa6K4eqFyIi+SzTB66ucI89I+yz3ZzSWZmGoSRsOwniz tXnS8GdPTuejU+5yA6qILmNbD6qxHrblspcwsrFeaT3gK3gaGL/oaPXjh6Sllqmx +DyhpPtQ3T0MiYQb0GDdxi1wARuFGaA1jC3ufSrCHmXglufQIyvHvnXc1w35AAQx 393JnS1TsZ8HphASPCiBzy91ttWcGkdLPAlX8ZJR4wBpP5FMqcJJQvRGo82NL9Hx 48Jz3lHpFMGRG8RlQRe33x1GiNR6fsLqBY8m1zgpFeQHbHIxGxYgWIF3nriDw51H /yPl6Qhjw/31tc4kJ8mq =m60X -----END PGP SIGNATURE----- --Apple-Mail=_0ADC3D5A-DF91-4825-ABDA-863E50C35313-- From owner-freebsd-arch@FreeBSD.ORG Tue Dec 16 23:38:48 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DD3C8AA; Tue, 16 Dec 2014 23:38:48 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E703B356; Tue, 16 Dec 2014 23:38:47 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 5D7703592FF; Wed, 17 Dec 2014 00:38:44 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id B89D628494; Wed, 17 Dec 2014 00:38:44 +0100 (CET) Date: Wed, 17 Dec 2014 00:38:44 +0100 From: Jilles Tjoelker To: John Baldwin Subject: Re: Change default VFS timestamp precision? Message-ID: <20141216233844.GA1490@stack.nl> References: <201412161348.41219.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201412161348.41219.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 23:38:48 -0000 On Tue, Dec 16, 2014 at 01:48:41PM -0500, John Baldwin wrote: > We still ship with vfs.timestamp_precision=0 by default meaning that > VFS timestamps have a granularity of one second. It is not unusual on > modern systems for multiple updates to a file or directory to occur > within a single second (and thus share the same effective timestamp). > This can break things that depend on timestamps to know when something > has changed or is stale (such as make(1) or NFS clients). On hardware > that has a cheap timecounter, I we should use the most-precise > timestamps (vfs.timestamp_precision=3). However, I'm less sure of > what to do for other cases such as i386/amd64 when not using TSC, or > on other platforms. OTOH, perhaps you aren't doing lots of heavy I/O > access on a system with a slow timecounter (or if you are doing heavy > I/O, slow timecounter access won't be your bottleneck)? > I can think of a few options: > 1) Change vfs.timestamp_precision default to 3 for all systems. > 2) Only change vfs.timestamp_precision default to 3 for amd64/i386 using an > #ifdef. > 3) Something else? Although some breakage may be caused, increasing precision sounds fine to me, but only to the level of microseconds, since there is no way to set a timestamp to the nanosecond (this would be futimens/utimensat). It is easy to be surprised when cp -p creates an file that appears older than the original. To avoid cross-arch surprises with applications that use second-resolution APIs, either all or no architectures should generate timestamps more accurate than seconds. There is no benefit for the particular case of make(1), since it only uses timestamps in seconds. A quick grep also shows various calls to utime(3) with a non-NULL timep argument. The ones in contrib/bmake and usr.bin/make definitely look incorrect. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Tue Dec 16 23:44:11 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ED05B2E; Tue, 16 Dec 2014 23:44:11 +0000 (UTC) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id AF93C614; Tue, 16 Dec 2014 23:44:10 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id CC97F1A46B3; Wed, 17 Dec 2014 10:43:56 +1100 (AEDT) Date: Wed, 17 Dec 2014 10:43:55 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin Subject: Re: Change default VFS timestamp precision? In-Reply-To: <201412161348.41219.jhb@freebsd.org> Message-ID: <20141217085846.G1087@besplex.bde.org> References: <201412161348.41219.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R8o6R7hX c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=wLjg0dudAHz73baaL-UA:9 a=lFHRPoQYm1Yx_HxI:21 a=E9i9pplvN6j1wK6l:21 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 23:44:11 -0000 On Tue, 16 Dec 2014, John Baldwin wrote: > We still ship with vfs.timestamp_precision=0 by default meaning that VFS > timestamps have a granularity of one second. It is not unusual on modern > systems for multiple updates to a file or directory to occur within a single > second (and thus share the same effective timestamp). This can break things > that depend on timestamps to know when something has changed or is stale (such > as make(1) or NFS clients). On hardware that has a cheap timecounter, I we > should use the most-precise timestamps (vfs.timestamp_precision=3). However, vfs.timestamp_precision=3 is too precise. It is still impossible to preserve nanoseconds resolution in backups and file copies, since no syscalls support writing it and few backup formats support saving it (dump/restore(8) format supports saving it, but then restore(8) silently truncates to microseconds. In the other direction, POSIX is still far from specifying rounding of unrepresentable times. In the 2007 version, for utimes() it just says that: (1) "[for times in the timeval struct] rounding towards the nearest second may occur" (2) "[for the null timeval pointer case] times of the file shall be set to the current time" (1) allows all sorts of rounding provided it is to nearest. Rounding to nearest has some advantage but is inconsistent with normal practice for times. (2) is impossible to satisfy if the current time is not representable as a file time. FreeBSD now uses vfs_timestamp() to fetch the current time in case (2). (2) seems to forbid this (unless vfs_timestamp() gives the current time). The implementation has the following style bugs: - vfs.timestamp_precision is not documented in any user man page (it is documented in vfs_timestamp(9)) - the kernel documentation is cloned ad nauseum into 2 other places, except for different wording errors: from vfs_subr.c: X /* X * Knob to control the precision of file timestamps: X * X * 0 = seconds only; nanoseconds zeroed. X * 1 = seconds and nanoseconds, accurate within 1/HZ. X * 2 = seconds and nanoseconds, truncated to microseconds. X * >=3 = seconds and nanoseconds, maximum precision. X */ This was once the only documentation. It is not very useful in the kernel, since it does less than echo the code. X enum { TSP_SEC, TSP_HZ, TSP_USEC, TSP_NSEC }; The code also uses this enum obfuscation. This is just an obfuscation, since the enum values are private and have to be translated into 0, 1, 2 and 3 in documentation and in the user API. So the user places that would benefit from names instead of magic numbers can see only the magic numbers, while the kernel places that get negative benefits from the names use both. Bugs in the above comment include: - case 1 is not accurate to 1/HZ, but to tc_tick/HZ. tc_tick is just usually 1. - no accuracy is guaranteed in case 1. It is a certain precision that is guranteed, matching the name of the sysctl. - real documention would also describe the details of the rounding in case 1. It is not simple truncation to a multiple of tc_tick/HZ, although that behaviour would be most useful. The actual behaviour is to leave near-noise in the low digits of tv_nsec. The low 3 digits are almost always 0, so they cannot be copied or backed up, giving the problems as in case 3 with no benefits except faster operation. - the behaviour for (garbage) negative values is not described, although the behaviour for (garbage) values >3 is described. - the differences between accuracy, precision and resolution are especially confusing in case 3 where the precision bumps into the resolution. Clearly the resolution for all cases is that of timespecs, i.e., nanoseconds. But nanoseconds precision is not possible with any supported hardware -- even with a 4GHz TSC as the timecounter, the precision of the timecounter read is a bit fuzzier than 1/4 nanoseconds. The APCI-fast clock has a frequency of ~14 MHz IIRC, so its precision is at most 1/14 microseconds = 70 nanoseconds. A real man page would give a hint about this. The documentation in vfs_timestamp(9) consists mainly of cloning the above comment. X static int timestamp_precision = TSP_SEC; X SYSCTL_INT(_vfs, OID_AUTO, timestamp_precision, CTLFLAG_RW, X ×tamp_precision, 0, "File timestamp precision (0: seconds, " X "1: sec + ns accurate to 1/HZ, 2: sec + ns truncated to ms, " X "3+: sec + ns (max. precision))"); Sysctl descriptions are are not the place to write man pages. This is another bad copy of what should be in a user man page. It is not quite as verbose as the comment, but has an additional error from abbreviations: "microseconds" is misabbreviated to "ms", ("milliseconds"). Quick fix (also fix other style bugs): SYSCTL_INT(_vfs, OID_AUTO, timestamp_precision, CTLFLAG_RW, ×tamp_precision, 0, "File timestamp precision (0: secs; 1: ticks; 2: usecs; 3: nsecs)"); > I'm less sure of what to do for other cases such as i386/amd64 when not using > TSC, or on other platforms. OTOH, perhaps you aren't doing lots of heavy I/O > access on a system with a slow timecounter (or if you are doing heavy I/O, > slow timecounter access won't be your bottleneck)? File times are rarely updated since the updates are normally delayed (except in devfs, where accurate times are least needed so caching would be most beneficial). But the caching means that increasing the timestamp precision won't help much to fix the problem with make. Consider build activity where there are a lot of writes which produce cached mtimes. Some time later, make runs and causes these times to be updated by stat()ing the files. It then sees times that are about the same, and likely to be out of order with respect to the actual writes. Extra precision actually makes the problem worse: with seconds precision, make usually sees the same time for all files, but with nanoseconds precision it sees its own stat() order. The extra precision is only helpful when there is a certain serialization of the stat()s relative to the build operations. Make must have some magic to handle equal file times. When the file time of a source is equal to the file time of the target, make cannot know if the target file is up to date. Make succeeds unsafely in this case -- it considers the target to be up to date. Without this, with seconds resolution almost all builds would produce mostly out of date targets since most steps have run in much less than 1 second. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 01:07:04 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78C5077D; Wed, 17 Dec 2014 01:07:04 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2E2D65; Wed, 17 Dec 2014 01:07:03 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id C4A9F4279FE; Wed, 17 Dec 2014 11:39:38 +1100 (AEDT) Date: Wed, 17 Dec 2014 11:39:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jilles Tjoelker Subject: Re: Change default VFS timestamp precision? In-Reply-To: <20141216233844.GA1490@stack.nl> Message-ID: <20141217105256.J1490@besplex.bde.org> References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=AIISoSx1 c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=VaHR_doENNfmLM0zlY4A:9 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 01:07:04 -0000 On Wed, 17 Dec 2014, Jilles Tjoelker wrote: > Although some breakage may be caused, increasing precision sounds fine > to me, but only to the level of microseconds, since there is no way to > set a timestamp to the nanosecond (this would be futimens/utimensat). It > is easy to be surprised when cp -p creates an file that appears older > than the original. As I said in too many more words in another reply. > To avoid cross-arch surprises with applications that use > second-resolution APIs, either all or no architectures should generate > timestamps more accurate than seconds. That might be a feature for finding bugs. And it doesn't work for avoiding them, because foreign file systems may have uncontrollable timestamp precision. E.g., a foreign nfs server. > There is no benefit for the particular case of make(1), since it only > uses timestamps in seconds. Urk, I now rememeber seeing that 15-20 years ago and deciding that the problem with timestamps for make couldn't be very large. > A quick grep also shows various calls to utime(3) with a non-NULL timep > argument. The ones in contrib/bmake and usr.bin/make definitely look > incorrect. Do you mean that they are incorrect because they use utime(3) and not utimes(3), or just because they use the non-NULL timep? The latter is just a style bug in at least usr.bin/make. Since it hasn't caught up with the existence of utimes(3), it is reasonable for it to also have not caught up with the existence of the non-NULL timep. It just wants to set the time to the current time. It uses its own copy of the current time for this. Perhaps this is technically better too -- it makes "make -t" touch everything with the same time. This reminds me of related bugs in touch(1): - touch also tries first with a non-NULL timep. So it uses its own idea of the current time. This is normally the one returned a little in the past by gettimeofday(). It has microseconds resolution. This normally succeeds, giving a result that is inconsistent with the one that would result from using a NULL timep, since the kernel now honors vfs.timestamp_precision and that is not usually 2. - sometimes the first try fails. Then touch retries with a NULL timep, if the semantics allow this. Sometimes this succeeds. - sometimes both tries fail due to permissions problems. Then touch used to retry using read() and write(). Someone removed this, with the justification that all file systems support utimes(). But this is broken, since touching for read requires only read permission, while utimes() requires some sort of write permission. For touching for write, I don't see any problem now except for the above ordering problems: a NULL timep should be tried first since it requires fewer permissions and gives the best semantics; if it fails then there is no point in retrying with a non-NULL timep. The non-NULL timep in make gives the following bug since make doesn't retry with a NULL timep: make -t fails if the files ar writeable but not owned. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 12:21:47 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5761D7B4 for ; Wed, 17 Dec 2014 12:21:47 +0000 (UTC) Received: from mailrelay10.public.one.com (mailrelay10.public.one.com [195.47.247.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3DCF250 for ; Wed, 17 Dec 2014 12:21:45 +0000 (UTC) X-HalOne-Cookie: 30715931dcc5ddc580c00f6ae174a86bfde09d1d X-HalOne-ID: a7541f4c-85cb-11e4-9705-b82a72d06996 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cederstrand.dk; s=20140924; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=pcFm7KlPDbays1EniXBkjX5SXuISxtOsazbyRGArk7s=; b=NKm+oUAgdJL0LsHQMSTyMnN51GHraBkSWIicbAKahfVzaCXh9XSwsQZHywbyasQYR/AIim0b4NUKm /Q0755N2qH5iS6fhyz/tx8EQw3RxMEjHRGuKEWwuu1vrw94EdSkDNNOMPCQPhjRK2l2Y+yJls8zDjH avqxsisGLMe/lGE4= Received: from [192.168.1.58] (unknown [217.157.7.221]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA; Wed, 17 Dec 2014 09:04:05 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Change default VFS timestamp precision? From: Erik Cederstrand In-Reply-To: <201412161348.41219.jhb@freebsd.org> Date: Wed, 17 Dec 2014 10:04:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1087E8D0-4B2F-4941-BDCE-3D50264D7FBB@cederstrand.dk> References: <201412161348.41219.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1993) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 12:21:47 -0000 > Den 16/12/2014 kl. 19.48 skrev John Baldwin : >=20 > We still ship with vfs.timestamp_precision=3D0 by default meaning that = VFS=20 > timestamps have a granularity of one second. It is not unusual on = modern=20 > systems for multiple updates to a file or directory to occur within a = single=20 > second (and thus share the same effective timestamp). This can break = things=20 > that depend on timestamps to know when something has changed or is = stale (such=20 > as make(1) or NFS clients). Mistaking timestamps for uniqueness is really a design error of the = consumer. Changing granularity to milliseconds will diminish the = problem, but also create harder-to-debug problems when multiple updates = do happen in the same millisecond. Is there no other way than timestamps = to find out if a file has changed (apart from md5 which is too = expensive)? Erik= From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 14:58:53 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB14478B for ; Wed, 17 Dec 2014 14:58:53 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A43D597B for ; Wed, 17 Dec 2014 14:58:53 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E12BBB97A; Wed, 17 Dec 2014 09:58:51 -0500 (EST) From: John Baldwin To: Jilles Tjoelker Subject: Re: Change default VFS timestamp precision? Date: Wed, 17 Dec 2014 09:40:01 -0500 Message-ID: <2034186.iLaW9EGnEt@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <20141216233844.GA1490@stack.nl> References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 17 Dec 2014 09:58:52 -0500 (EST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 14:58:54 -0000 On Wednesday, December 17, 2014 12:38:44 AM Jilles Tjoelker wrote: > On Tue, Dec 16, 2014 at 01:48:41PM -0500, John Baldwin wrote: > > We still ship with vfs.timestamp_precision=0 by default meaning that > > VFS timestamps have a granularity of one second. It is not unusual on > > modern systems for multiple updates to a file or directory to occur > > within a single second (and thus share the same effective timestamp). > > This can break things that depend on timestamps to know when something > > has changed or is stale (such as make(1) or NFS clients). On hardware > > that has a cheap timecounter, I we should use the most-precise > > timestamps (vfs.timestamp_precision=3). However, I'm less sure of > > what to do for other cases such as i386/amd64 when not using TSC, or > > on other platforms. OTOH, perhaps you aren't doing lots of heavy I/O > > access on a system with a slow timecounter (or if you are doing heavy > > I/O, slow timecounter access won't be your bottleneck)? > > > > I can think of a few options: > > 1) Change vfs.timestamp_precision default to 3 for all systems. > > > > 2) Only change vfs.timestamp_precision default to 3 for amd64/i386 using > > an > > > > #ifdef. > > > > 3) Something else? > > Although some breakage may be caused, increasing precision sounds fine > to me, but only to the level of microseconds, since there is no way to > set a timestamp to the nanosecond (this would be futimens/utimensat). It > is easy to be surprised when cp -p creates an file that appears older > than the original. Note that vfs_timestamp() always returns a timespec, but 2 would do microseconds. The important difference for settings >= 2 is that it queries the timecounter on each call rather than using a global value that is only updated either once a second or once a millisecond or so. > To avoid cross-arch surprises with applications that use > second-resolution APIs, either all or no architectures should generate > timestamps more accurate than seconds. Actually, it will improve our interoperability with other OS's that already use sub-second timestamps when sharing filesystems over NFS, for example. > There is no benefit for the particular case of make(1), since it only > uses timestamps in seconds. My bad for not checking that further but for assuming make would be impacted. The use case I _am_ familiar with is NFS servers and NFS v3 clients that depend on the mtime of a directory to know when the lookup cache for a directory can be invalidated. Our NFS client now defaults to only trusting cached lookups for 60 seconds to workaround races due to seconds-granularity in timestamps from some NFS servers at the cost of reducing its effectiveness by a fair amount. Note that Isilon already defaults vfs.timestamp_precision to 3 on their appliances, and I recently convinced the folks at TrueNAS to do the same. However, it would also make stock FreeBSD NFS servers more reliable for NFS v3 if we changed our default. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 14:58:54 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BC6778C for ; Wed, 17 Dec 2014 14:58:54 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0532E97C for ; Wed, 17 Dec 2014 14:58:54 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D3893B982; Wed, 17 Dec 2014 09:58:52 -0500 (EST) From: John Baldwin To: Erik Cederstrand Subject: Re: Change default VFS timestamp precision? Date: Wed, 17 Dec 2014 09:34:38 -0500 Message-ID: <1524396.mnvXrYilFC@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <1087E8D0-4B2F-4941-BDCE-3D50264D7FBB@cederstrand.dk> References: <201412161348.41219.jhb@freebsd.org> <1087E8D0-4B2F-4941-BDCE-3D50264D7FBB@cederstrand.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 17 Dec 2014 09:58:52 -0500 (EST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 14:58:54 -0000 On Wednesday, December 17, 2014 10:04:08 AM Erik Cederstrand wrote: > > Den 16/12/2014 kl. 19.48 skrev John Baldwin : > > > > We still ship with vfs.timestamp_precision=0 by default meaning that VFS > > timestamps have a granularity of one second. It is not unusual on modern > > systems for multiple updates to a file or directory to occur within a > > single second (and thus share the same effective timestamp). This can > > break things that depend on timestamps to know when something has changed > > or is stale (such as make(1) or NFS clients). > > Mistaking timestamps for uniqueness is really a design error of the > consumer. Changing granularity to milliseconds will diminish the problem, > but also create harder-to-debug problems when multiple updates do happen in > the same millisecond. Is there no other way than timestamps to find out if > a file has changed (apart from md5 which is too expensive)? For NFS v3 clients, no. And the bigger case is directories and knowing when to purge the results of cached lookups. Right now our NFS client defaults to a hard timeout of 60 seconds for any lookups it caches to limit the damage from losing races when a directory has multiple states that are associated with the same 'mtime'. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 17:28:31 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C967D28; Wed, 17 Dec 2014 17:28:31 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D25631BF4; Wed, 17 Dec 2014 17:28:30 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2B2C43BD1A; Wed, 17 Dec 2014 17:28:22 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sBHHSLn1070074; Wed, 17 Dec 2014 17:28:21 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin Subject: Re: Change default VFS timestamp precision? In-reply-to: <2034186.iLaW9EGnEt@ralph.baldwin.cx> From: "Poul-Henning Kamp" References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> <2034186.iLaW9EGnEt@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70072.1418837301.1@critter.freebsd.dk> Date: Wed, 17 Dec 2014 17:28:21 +0000 Message-ID: <70073.1418837301@critter.freebsd.dk> Cc: arch@freebsd.org, Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:28:31 -0000 -------- In message <2034186.iLaW9EGnEt@ralph.baldwin.cx>, John Baldwin writes: >My bad for not checking that further but for assuming make would be impacted. I think it is over 10 years ago when make(1) first started seeing identical timestamps which wasn't. In most Makefiles this doesn't matter, but there are cases, in particular in less integrated families of makefiles than our own. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 19:02:47 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8663138E; Wed, 17 Dec 2014 19:02:47 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 17710C59; Wed, 17 Dec 2014 19:02:47 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id l2so21286897wgh.27 for ; Wed, 17 Dec 2014 11:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AbCYKYkXTo+f6bZiOjaOMC9tWszOLoHRX3FgDzd6zsE=; b=ox6i7/vmg7liP7hrvkOwahWYdQpJfiDkr7ZywZiceGUKy7lv4UPd/xvo2jlQe6+kzY HD0bxZZsnLqsVvXcVmohigCRSIG2q9NhCA+aZWxtczVwmFzvqgAL6MrLeonWGrSpelip V4lbBANvgPpPAuW6m3aj1pgaBFj5guRB6qnQ+SVI/7ffmB7BBUKB53wxIK36gOD5Lvn5 devazerquiledWis1du0x1fr2+VkSqJ5Tfa0It8QxbK0sCnDirDaeAFovs4W58I0Cg/x JdZbgUswYA10B+6CjbD2wX8xVS7y92Lfh02dT1Pzry+Tc5W8QOrKI631UAEe+D4x5vqN S48Q== MIME-Version: 1.0 X-Received: by 10.194.108.9 with SMTP id hg9mr36755240wjb.68.1418842965454; Wed, 17 Dec 2014 11:02:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Wed, 17 Dec 2014 11:02:45 -0800 (PST) In-Reply-To: <70073.1418837301@critter.freebsd.dk> References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> <2034186.iLaW9EGnEt@ralph.baldwin.cx> <70073.1418837301@critter.freebsd.dk> Date: Wed, 17 Dec 2014 11:02:45 -0800 X-Google-Sender-Auth: PBktTGHdnB8V4eg3266N2a_hoe0 Message-ID: Subject: Re: Change default VFS timestamp precision? From: Adrian Chadd To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:02:47 -0000 On 17 December 2014 at 09:28, Poul-Henning Kamp wrote: > -------- > In message <2034186.iLaW9EGnEt@ralph.baldwin.cx>, John Baldwin writes: > >>My bad for not checking that further but for assuming make would be impacted. > > I think it is over 10 years ago when make(1) first started seeing > identical timestamps which wasn't. > > In most Makefiles this doesn't matter, but there are cases, in particular > in less integrated families of makefiles than our own. Surely there has to be better ways of doing this stuff. Computers keep getting faster; it wouldn't be out of the realm of possibility that we could see a compiler read, compile and spit out a .o inside of a millisecond. (Obviously not C++, but..) -adrian From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 19:09:17 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 832D65A4; Wed, 17 Dec 2014 19:09:17 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 40E70CDE; Wed, 17 Dec 2014 19:09:16 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 733E33BD1A; Wed, 17 Dec 2014 19:09:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sBHJ9EcC070450; Wed, 17 Dec 2014 19:09:15 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd Subject: Re: Change default VFS timestamp precision? In-reply-to: From: "Poul-Henning Kamp" References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> <2034186.iLaW9EGnEt@ralph.baldwin.cx> <70073.1418837301@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70448.1418843354.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Dec 2014 19:09:14 +0000 Message-ID: <70449.1418843354@critter.freebsd.dk> Cc: "freebsd-arch@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:09:17 -0000 -------- In message , Adrian Chadd writes: >> I think it is over 10 years ago when make(1) first started seeing >> identical timestamps which wasn't. >> >> In most Makefiles this doesn't matter, but there are cases, in particul= ar >> in less integrated families of makefiles than our own. > >Surely there has to be better ways of doing this stuff. Computers keep >getting faster; it wouldn't be out of the realm of possibility that we >could see a compiler read, compile and spit out a .o inside of a >millisecond. (Obviously not C++, but..) A millisecond is pushing it, all things considered, it would have to be an utterly trivial source file for a utterly trivial language. Given that it has epsilon cost, switching to TSP_HZ should be a no-brainer, I've been running that for ages. Why TSP_USEC exists is beyond me, it's slower and worse than TSP_NSEC. But going to TSP_NSEC by default seems unwarranted to me. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 19:31:42 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 641B3DF; Wed, 17 Dec 2014 19:31:42 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07288101D; Wed, 17 Dec 2014 19:31:42 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id y19so21134212wgg.21 for ; Wed, 17 Dec 2014 11:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZnU9xTt+nNOAIlBQum8n8tcpZ8SEcD5XijswDD2lRnI=; b=piqdKUaXqhgFj3AVcezJjKlLYlIrZvH2GfFqftA11UbmhqItOV2poiKFRt70Q/N3aj /5TTWB41Sv0vjoSFyDDKczSFDBs5FFwCYy/HT4mDPTAusvJ/laKNkK6j+SZKGBVtz85k esk/RSepREVSMLB+yyVeEeTV07jN7R8YHYKTP/5Bkp/KZo5iNiuommY+3cNEbY7tdAs1 4NgGOivHiZcN7C1E23m6fQdk21dwH+tkIYKvUE3IgqVP9LPaW1NGkSy32xP6ktDCXR0O QmqVkgx32vdG/fW734Y2/zdDnQGg03kujzBTcvX+0GXp02zlfFZbWBfErF8aSeolkvrG UDrw== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr77193878wjz.20.1418844700455; Wed, 17 Dec 2014 11:31:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Wed, 17 Dec 2014 11:31:40 -0800 (PST) In-Reply-To: <70449.1418843354@critter.freebsd.dk> References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> <2034186.iLaW9EGnEt@ralph.baldwin.cx> <70073.1418837301@critter.freebsd.dk> <70449.1418843354@critter.freebsd.dk> Date: Wed, 17 Dec 2014 11:31:40 -0800 X-Google-Sender-Auth: coSxUwqbecx51C2SFQuRs7iaxfE Message-ID: Subject: Re: Change default VFS timestamp precision? From: Adrian Chadd To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:31:42 -0000 On 17 December 2014 at 11:09, Poul-Henning Kamp wrote: > -------- > In message > , Adrian Chadd writes: > >>> I think it is over 10 years ago when make(1) first started seeing >>> identical timestamps which wasn't. >>> >>> In most Makefiles this doesn't matter, but there are cases, in particular >>> in less integrated families of makefiles than our own. >> >>Surely there has to be better ways of doing this stuff. Computers keep >>getting faster; it wouldn't be out of the realm of possibility that we >>could see a compiler read, compile and spit out a .o inside of a >>millisecond. (Obviously not C++, but..) > > A millisecond is pushing it, all things considered, it would have to > be an utterly trivial source file for a utterly trivial language. Why? Computers can do a ridiculous amount of work in a millisecond. Assuming you're doing something daft like compiling a large C++ thing, the actual inefficiencies that bites you is all the overhead in fork, exec, demand paging in things, setting it up, etc. If your file generation is instead from some persistent "thing" that's not fork/exec/faulting/setup/teardown/writing/syncing and it's translating from source X to representation Y (and this can be a compiler, but I was doing this with some linguistic hacks whilst at uni) a lot of work gets done in that millisecond. > Given that it has epsilon cost, switching to TSP_HZ should be a > no-brainer, I've been running that for ages. > > Why TSP_USEC exists is beyond me, it's slower and worse than TSP_NSEC. > > But going to TSP_NSEC by default seems unwarranted to me. Right, but using TSP_NSEC only makes sense if (a) we get actual nanosecond precision, and (b) we have some guarantee that when you modify a file, the timestamp value is at least incremented by say, a nanosecond. Rather than the rather silly setup where you ask for NSEC or USEC (or heck, MSEC) and you end up changing a file very rapidly within the resolution of the timecounter API being used. I've been bitten by this - and I've had to hack things up to increment a nanosecond counter to treat it as a poor mans generation counter, documenting that if you change this object more than say a million times a second, you may hit issues. (All because things don't have a generational counter, they have a timestamp, and computers got really fast really quickly.) -adrian From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 19:49:44 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83DDE529; Wed, 17 Dec 2014 19:49:44 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A09511ED; Wed, 17 Dec 2014 19:49:44 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id y13so16890987pdi.3 for ; Wed, 17 Dec 2014 11:49:43 -0800 (PST) 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 :message-id:references:to; bh=kkSAJIPZErNIP5k4gjYNLmCsLY9kp1ULMWuBkYTzl44=; b=q+ddgSUb1GSS+57xj8y7NN1MVd945JBCny2Zuzu1l1QVtxyxOrGeoOV+HtUvZz3ZA6 VRdVsFTjxaZ9jyR2QX+TkMraPNd5Zy+e+IlsJMi+m00N6KYS16W4geFR+S1cea2Cki35 27651/OKFg2rQW3orLa0gadS83rQJl2cSNH5fkvd9K/sRaMKRWcgQdSJFMR2zlEWm+pO +wdQjVvceI7qgZsyH2DAl2+errIgdtVEEoNCWP+u+/TV/JXBQqTnFPwDFy7EFXUgd+sh H6YmzKMS9wE/Tv++F7VDaOyvX6jqxkpnVYUw0GeB7qJvFTbsgL5MPMnIvjbQ2z1jqZ0K IfLQ== X-Received: by 10.68.172.34 with SMTP id az2mr71772616pbc.113.1418845783757; Wed, 17 Dec 2014 11:49:43 -0800 (PST) Received: from [192.168.20.5] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id nz4sm4642240pdb.69.2014.12.17.11.49.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Dec 2014 11:49:43 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DE47CF0E-56AA-4000-ADDD-446C5AF35C1E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: _bootstrap-tools parallel build (was: Re: CFR, CFT: Fine-grained SUBDIR dependencies for parallel builds From: Garrett Cooper In-Reply-To: Date: Wed, 17 Dec 2014 11:49:41 -0800 Message-Id: <8F3BDC42-83EE-46FA-AEFB-F35561290D48@gmail.com> References: To: Jia-Shiun Li X-Mailer: Apple Mail (2.1878.6) Cc: Ian Lepore , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:49:44 -0000 --Apple-Mail=_DE47CF0E-56AA-4000-ADDD-446C5AF35C1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 15, 2014, at 21:00, Jia-Shiun Li wrote: > On Sat, May 31, 2014 at 10:04 PM, Ian Lepore wrote: >>=20 >> The parallelism in the bootstrap stuff in Makefile.inc1 is done with = a >> different-but-similar mechanism, and it would be nice to fix that to >> just use bsd.subdir.mk instead of almost-duplicating it inline. = That's >> on a longer-term to-do list for me. >>=20 >=20 > Hi Ian & all, >=20 > I did it manually for _bootstrap-tools anyway. Patches attached. >=20 > It reduces 'make -j24 _botostrap-tools' time from ~55 sec. to ~25 sec. > on a 12C IVB-EP. > It scales more linearly in comparison to single-job ~250 sec on the > same machine. > Main blockers were tblgen & groff. >=20 > On -j4 it reduces time from ~82 sec. to ~60 sec. too. >=20 > It passed 'make -j24 universe' except the seemingly broken i386 = kernels. >=20 > Any comments? Hi Jia-Shiun! I submitted the gnu/usr.bin/groff portion of your patch in = r275866 . I=92m going to look at stripping down bootstrap-tools, et al a = bit more in the next couple days and I=92ll be using your patch in part = with some parallel efforts I=92ve done on a branch on my github fork as = well: https://github.com/yaneurabeya/freebsd/tree/faster-build . Thank you! --Apple-Mail=_DE47CF0E-56AA-4000-ADDD-446C5AF35C1E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEbBAEBCgAGBQJUkd5VAAoJEMZr5QU6S73eluoH+MIyjUBfSsG2XIJ/bDIE7aU6 QYl6otb/aPE9Ayuc80HD/M+3uzQJEx+aaqAqkyLPdsRZpypo2nfQE57uqSHvSJu0 eB4gkoF6cRA8WuZeo9ozBtRUud3WQj9JwOjta+DLVCfSGDnoHSxFrDI1v7Zmfhj9 ikhimJygh5afUEsx0nAUKKLObjf9/cfgNUfIr3bhSXRRmCFVPBS1fWjRg1VMuTkH cgPSOYAIxN04oDRSiXFEhVqDG5dJt+J/6xSatmzL+AV3nITCutVx6BEkCgtTCTf/ PJ1ErTFzZKeM/Dgd4+OMnzSI2o1BbZlgBFWRSsu4BJpZU3JLysY0cU2h3/VbBQ== =IFZq -----END PGP SIGNATURE----- --Apple-Mail=_DE47CF0E-56AA-4000-ADDD-446C5AF35C1E-- From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 19:56:17 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02E5665F; Wed, 17 Dec 2014 19:56:17 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B3C8012D6; Wed, 17 Dec 2014 19:56:16 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 62F953BD3A; Wed, 17 Dec 2014 19:56:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sBHJuEab070617; Wed, 17 Dec 2014 19:56:14 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd Subject: Re: Change default VFS timestamp precision? In-reply-to: From: "Poul-Henning Kamp" References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> <2034186.iLaW9EGnEt@ralph.baldwin.cx> <70073.1418837301@critter.freebsd.dk> <70449.1418843354@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70615.1418846174.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Dec 2014 19:56:14 +0000 Message-ID: <70616.1418846174@critter.freebsd.dk> Cc: "freebsd-arch@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:56:17 -0000 -------- In message , Adrian Chadd writes: >> A millisecond is pushing it, all things considered, it would have to >> be an utterly trivial source file for a utterly trivial language. > >Why? Computers can do a ridiculous amount of work in a millisecond. Yes, but try it yourself, they mostly don't. One millisecond is only about a million instructions if you are lucky, and in difference from system III, we have put an awful lot of code between the stuff you want done and the hardware that does it. So show me, and I'll belive you. >Right, but using TSP_NSEC only makes sense if (a) we get actual >nanosecond precision, and (b) we have some guarantee that when you >modify a file, the timestamp value is at least incremented by say, a >nanosecond. No. TSP_NSEC makes sense if TSP_HZ isn't enough, and it is the next logical step we can provide. If you want better than TSP_NSEC, the first thing to do is beat Intel and AMD up until the provide better timekeeping hardware in their CPUs. Once that's done, use this hardware for timecounters and TSP_NSEC will automatically improve. >I've been bitten by this - and I've had to hack things up to increment >a nanosecond counter to treat it as a poor mans generation counter, That's Lamports (in)famous solution :-) However, this doesn't really have *anything* to do with VFS timestamps, because there is NFW the objects you were timestamping were VFS files if nanosecond resolution were required. VFS timestamps are a performance trade-off, and if you want TSP_NSEC you can set TSP_NSEC, but for a sensible default TSP_HZ is the thing. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 20:55:23 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAF5F537; Wed, 17 Dec 2014 20:55:23 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B09C71BB7; Wed, 17 Dec 2014 20:55:23 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D66AB3592F1; Wed, 17 Dec 2014 21:55:20 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 2257828494; Wed, 17 Dec 2014 21:55:21 +0100 (CET) Date: Wed, 17 Dec 2014 21:55:21 +0100 From: Jilles Tjoelker To: Bruce Evans Subject: Re: Change default VFS timestamp precision? Message-ID: <20141217205520.GB10644@stack.nl> References: <201412161348.41219.jhb@freebsd.org> <20141217085846.G1087@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141217085846.G1087@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:55:24 -0000 On Wed, Dec 17, 2014 at 10:43:55AM +1100, Bruce Evans wrote: > On Tue, 16 Dec 2014, John Baldwin wrote: > > I'm less sure of what to do for other cases such as i386/amd64 when > > not using TSC, or on other platforms. OTOH, perhaps you aren't > > doing lots of heavy I/O access on a system with a slow timecounter > > (or if you are doing heavy I/O, slow timecounter access won't be > > your bottleneck)? > File times are rarely updated since the updates are normally delayed (except > in devfs, where accurate times are least needed so caching would be most > beneficial). But the caching means that increasing the timestamp precision > won't help much to fix the problem with make. Consider build activity > where there are a lot of writes which produce cached mtimes. Some time > later, make runs and causes these times to be updated by stat()ing the > files. It then sees times that are about the same, and likely to be out > of order with respect to the actual writes. Extra precision actually > makes the problem worse: with seconds precision, make usually sees the > same time for all files, but with nanoseconds precision it sees its own > stat() order. The extra precision is only helpful when there is a > certain serialization of the stat()s relative to the build operations. This would be strange and indeed it does not work that way. Per POSIX, timestamps marked for update must also be updated when the file ceases to be open by any process; FreeBSD updates them on any file close (VOP_CLOSE). Therefore, the timestamps reflect at latest the time the files were closed, when looked at after the writing program is done. The problems you describe only occur when the affected files remain open, which is not the case in usual build processes. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 21:11:14 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0A6D8E3; Wed, 17 Dec 2014 21:11:14 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E6671DD7; Wed, 17 Dec 2014 21:11:14 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id k14so5308123wgh.1 for ; Wed, 17 Dec 2014 13:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fxjIFp6v+2H8YMlMjcKx2Fkk2/Jkn9Zmpd3BhRBYVcs=; b=ANVwF92npvx0oOuQFIcBMB47zoWiSEgUSz6xfL9pvq1gmDUUOMtbGL3iYbBVbvcGhy hbQn/TN6RlQITjMp4uubanfzsAMCG2tw4mKIpMoPIV8IgYHBRNEP+KfvNL5ngEIsBYzk D5E3uZP6ZhTEovCY2QBc0GiFnPJixZH+NLEN8XRDuuCq3EnwldUm+mL6koVWU+6nOtRK e21xoobshwfeG6xDcN1zcDq6oXulpe1p8n9dE+y+soa7ybPgcCKi+4rfITDzaml6gzFs Bm9XFc3D+5bcKWNv+/YY3NzbL2aGutjwnOQUhXLbFLujD6H8CFAih+Lh59GIBIM1z+Pz /6pQ== MIME-Version: 1.0 X-Received: by 10.180.20.6 with SMTP id j6mr17690055wie.59.1418850672489; Wed, 17 Dec 2014 13:11:12 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Wed, 17 Dec 2014 13:11:12 -0800 (PST) In-Reply-To: <70616.1418846174@critter.freebsd.dk> References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> <2034186.iLaW9EGnEt@ralph.baldwin.cx> <70073.1418837301@critter.freebsd.dk> <70449.1418843354@critter.freebsd.dk> <70616.1418846174@critter.freebsd.dk> Date: Wed, 17 Dec 2014 13:11:12 -0800 X-Google-Sender-Auth: DaSdLLJgh5_LqIJH3oMge6cyAzw Message-ID: Subject: Re: Change default VFS timestamp precision? From: Adrian Chadd To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 21:11:14 -0000 On 17 December 2014 at 11:56, Poul-Henning Kamp wrote: > -------- > In message > , Adrian Chadd writes: > >>> A millisecond is pushing it, all things considered, it would have to >>> be an utterly trivial source file for a utterly trivial language. >> >>Why? Computers can do a ridiculous amount of work in a millisecond. > > Yes, but try it yourself, they mostly don't. > > One millisecond is only about a million instructions if you are lucky, > and in difference from system III, we have put an awful lot of code > between the stuff you want done and the hardware that does it. > > So show me, and I'll believe you. If I can find the code from a few years ago, sure. A lot of stuff from my arts degree is sitting on hard disks in Australia, waiting to be plugged in again. (Next time I come up against this I'll show you. :) -adrian From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 22:21:59 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00251BC9; Wed, 17 Dec 2014 22:21:58 +0000 (UTC) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id A0DE78F6; Wed, 17 Dec 2014 22:21:57 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 063E3780BDF; Thu, 18 Dec 2014 09:03:38 +1100 (AEDT) Date: Thu, 18 Dec 2014 09:03:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Erik Cederstrand Subject: Re: Change default VFS timestamp precision? In-Reply-To: <1087E8D0-4B2F-4941-BDCE-3D50264D7FBB@cederstrand.dk> Message-ID: <20141218075519.J1025@besplex.bde.org> References: <201412161348.41219.jhb@freebsd.org> <1087E8D0-4B2F-4941-BDCE-3D50264D7FBB@cederstrand.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=C77Ql2/+ c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=6I5d2MoRAAAA:8 a=EBiVJ97NH1EGm-4m700A:9 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 22:21:59 -0000 On Wed, 17 Dec 2014, Erik Cederstrand wrote: >> Den 16/12/2014 kl. 19.48 skrev John Baldwin : >> >> We still ship with vfs.timestamp_precision=0 by default meaning that VFS >> timestamps have a granularity of one second. It is not unusual on modern >> systems for multiple updates to a file or directory to occur within a single >> second (and thus share the same effective timestamp). This can break things >> that depend on timestamps to know when something has changed or is stale (such >> as make(1) or NFS clients). > > Mistaking timestamps for uniqueness is really a design error of the consumer. Changing granularity to milliseconds will diminish the problem, but also create harder-to-debug problems when multiple updates do happen in the same millisecond. Is there no other way than timestamps to find out if a file has changed (apart from md5 which is too expensive)? Milliseconds granularity is not even supported (the sysctl description just misspells microseconds as ms). For unique file timestamps, the timestamps could be made unique by fudging the nanoseconds part. Increment by 1 on each access the current time didn't change since the last access. Since nansoeconds granularity is not supported for writing, actually increment by 1000 nanoseconds on each access if the current time changed by less than 1000 nanoseconds, and also round to a multiple of 1000. In the unlikely event that the accesses are more frequent than once per microsecond, then let the timestamp clock run a bit ahead of real time, but not too much. Oops. I have tests that the timestamp clock runs coherently with real time. These fail now unless the timestamp clock is the same as the real time clock (consistently rounded down to the granularity of the clock used in the tests, which is the real time clock rounded down to seconds). I.e., they fail for vfs.timestamp_precision = 0 or 1, since these give an clock that lags the real time clock incoherently with the rounding. Fudging the timestamp clock would break the tests in other ways, especially if "a bit a head of real time" means a few hundred microseconds. So perhaps don't increment by a full 1000 nanoseconds or round to microseconds if that would advance the clock too fast. This fails when the accesses arrive faster than once per nanoseconds, but that will remain physically impossible for some time (but see below about multiple CPUs and locking). I think Solaris does something like this. Perhaps there are traces of it in zfs. This would be useless for BSD make since it only uses seconds resolution. Note that this is also almost useless if the file system does any caching of timestamp updates, like most file systems do. Timestamp updates normally occur when a program stat()s the file. So after write to file 1; write to file 2; stat() of file 2; stat() of file 1, all the monotonically increasing timestamp clock does is ensure that the stat()s give a perfectly wrong order. The only way to ensure getting the right order is to do the stat()s in the same order as the writes, but if the right order is known then it is unnecessary to do the stat()s to determine the order. If this were not useless, then it might be worth implementing. Then there would be difficult to make it efficient: - the simplest implementation is to axe all the caching and nanoseconds resolution. This mostly gives strictly monotonically increasing timestamps, but not always. Failing cases include: - someone steps the clock - the timecounter precision is much lower than nanoseconds - the system has multiple CPUs, and timestamps are made concurrently. The same timestamp may be made on different CPUs (most likely on different filesystems -- otherwise locking would serialize things). Then the write times probably aren't exactly the same, but you can't tell. Even when the timestamps differ by 1 nanosecond, just making them has a fuzziness of more than 1 nanosecond so you still can't determine the exact order of the writes. - otherwise, the cached timestamps must be serialized across CPUs and file systems. E.g., in ffs where it currently marks the mtime for update using `ip->i_flag |= IN_UPDATE' (locked by the vnode interlock), it would also have to incremement a generation counter or something. The lock for this would have to be across all CPUs and file systems. It would be a fine source of lock contention. Timecounter update code has complications to avoid such contention. Then when the update occurs, somhow combine the generation counter with real-time timestamps. I think it works to do something like 'timestamp.tv_sec = old_time; timestamp.tv_nsec = generation_count', where old_time is the time for the current set of generations (start a new set of generations every second after updating all timestamps for the old generation). - combine these methods: replace marking for update with updating as in the first method, and serialize this using fine lock contention as in the second method. The lock gives an ordering on the update operations, and while it is held it is easy to fudge the timestamps to represent this ordering. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 23:00:52 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C652812A for ; Wed, 17 Dec 2014 23:00:52 +0000 (UTC) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EE57CC6 for ; Wed, 17 Dec 2014 23:00:52 +0000 (UTC) X-ASG-Debug-ID: 1418857233-08ca044763c37b0002-Z4wkSQ Received: from [10.143.185.61] (mobile-166-170-037-232.mycingular.net [166.170.37.232]) by barracuda.ixsystems.com with ESMTP id 01uM6imcoSWDFDGo (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 15:00:36 -0800 (PST) X-Barracuda-Envelope-From: jkh@ixsystems.com X-Barracuda-AUTH-User: jkh@ixsystems.com X-Barracuda-Apparent-Source-IP: 166.170.37.232 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Change default VFS timestamp precision? From: Jordan Hubbard X-ASG-Orig-Subj: Re: Change default VFS timestamp precision? X-Mailer: iPhone Mail (12B440) In-Reply-To: <70449.1418843354@critter.freebsd.dk> Date: Wed, 17 Dec 2014 15:00:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> <2034186.iLaW9EGnEt@ralph.baldwin.cx> <70073.1418837301@critter.freebsd.dk> <70449.1418843354@critter.freebsd.dk> To: Poul-Henning Kamp X-Barracuda-Connect: mobile-166-170-037-232.mycingular.net[166.170.37.232] X-Barracuda-Start-Time: 1418857236 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.13030 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Cc: "freebsd-arch@freebsd.org" , Adrian Chadd , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 23:00:52 -0000 "640k should be enough for anyone." I think that's a sucker's bet you just made. FWIW, we have already been asked to set this value to three. Something to do= with high frequency stock trading I think! Sent from my iPhone > On Dec 17, 2014, at 11:09, Poul-Henning Kamp wrote: >=20 > A millisecond is pushing it, all things considered, it would have to > be an utterly trivial source file for a utterly trivial language. From owner-freebsd-arch@FreeBSD.ORG Thu Dec 18 01:06:45 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C5124F5; Thu, 18 Dec 2014 01:06:45 +0000 (UTC) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id D3DE91B4E; Thu, 18 Dec 2014 01:06:44 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 0F417D41F06; Thu, 18 Dec 2014 11:38:27 +1100 (AEDT) Date: Thu, 18 Dec 2014 11:38:25 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jilles Tjoelker Subject: Re: Change default VFS timestamp precision? In-Reply-To: <20141217205520.GB10644@stack.nl> Message-ID: <20141218104134.W15347@besplex.bde.org> References: <201412161348.41219.jhb@freebsd.org> <20141217085846.G1087@besplex.bde.org> <20141217205520.GB10644@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R8o6R7hX c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=PHl3pb4zV4KDLrYAcl0A:9 a=ey0TfqP3e2sX61iL:21 a=zrzB1_NWRgG_owhH:21 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 01:06:45 -0000 On Wed, 17 Dec 2014, Jilles Tjoelker wrote: > On Wed, Dec 17, 2014 at 10:43:55AM +1100, Bruce Evans wrote: >> On Tue, 16 Dec 2014, John Baldwin wrote: >>> I'm less sure of what to do for other cases such as i386/amd64 when >>> not using TSC, or on other platforms. OTOH, perhaps you aren't >>> doing lots of heavy I/O access on a system with a slow timecounter >>> (or if you are doing heavy I/O, slow timecounter access won't be >>> your bottleneck)? > >> File times are rarely updated since the updates are normally delayed (except >> in devfs, where accurate times are least needed so caching would be most >> beneficial). But the caching means that increasing the timestamp precision >> won't help much to fix the problem with make. Consider build activity >> where there are a lot of writes which produce cached mtimes. Some time >> later, make runs and causes these times to be updated by stat()ing the >> files. It then sees times that are about the same, and likely to be out >> of order with respect to the actual writes. Extra precision actually >> makes the problem worse: with seconds precision, make usually sees the >> same time for all files, but with nanoseconds precision it sees its own >> stat() order. The extra precision is only helpful when there is a >> certain serialization of the stat()s relative to the build operations. > > This would be strange and indeed it does not work that way. Per POSIX, > timestamps marked for update must also be updated when the file ceases > to be open by any process; FreeBSD updates them on any file close > (VOP_CLOSE). Therefore, the timestamps reflect at latest the time the > files were closed, when looked at after the writing program is done. Yes, there is also an update on [last] close. (It is usually only on last close -- e.g., ffs's VOP_CLOSE only does it if v_usecount > 1.). > The problems you describe only occur when the affected files remain > open, which is not the case in usual build processes. Only the problem with seeing the stat() order, and that problem is very small (all the problems are small, but I'm trying to think of them all). Consider some cc -c operations in parallel. Make has to wait for these cc's to exit. If close() didn't update, then make could stat the produced .o files to force the update. The resulting times are unordered relative to each other, so must not be used for for determining out-of-dateness of the generated files relative to each other, but it is hard to think of a valid makefile where these files depend on each other. (They shouldn't be built in parallel if they do depend on each other.) For directory and metadata operations, there is often no last close to force the update. The nfs problems mentioned in this thread are mostly for directories. nfs asks for directory times using GETATTR or similar. Thus is like stat(). It will update the times, but often just to the current time. This is enough for determining if the directory changed, provided the clock wasn't stepped backwards and has a fine enough granularity. It is useless for inter-file comparisons, since unlike for make, nfs cannot control the production or timestamp update of other files. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Dec 18 12:48:53 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0559C0B; Thu, 18 Dec 2014 12:48:53 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B69AF10AD; Thu, 18 Dec 2014 12:48:53 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id h15so797663igd.14; Thu, 18 Dec 2014 04:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=zp4uVUw8PZtaXIqEJSI5D1+g2kIChmE1t1DnhkT4UiQ=; b=UeP5HkmNWvT2kYJ62TSNksF+GYhOygr/ms76b6VAc5fKKqUhfntV0vcazwiQufBrXV zBh3WHprNAc7kiyHIpJpxDLNOCweVnD/+oqLwM0MBhRqED8KZaQ3WLCDYmQh3rEsRABF BiH4l8EJSODadHsDxoN2YMwjZGj/jMvBewFhy3am10fCxTSKzN4n7jfPE5bfk4Y1UF67 Btaa6gZskKCxbbHqNmNUT4ok8aSUEsbiqCD2hbSZWKNkiElErMoJ9ufUquan/rlOWP/x Llz+SuJJdmZ/8UEftiEo1lR16lKweeax3gsAdk2fMhgClHj5BfeHq4N1Y31C638rdioz o2CQ== X-Received: by 10.50.29.107 with SMTP id j11mr2117010igh.32.1418906932849; Thu, 18 Dec 2014 04:48:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.175.4 with HTTP; Thu, 18 Dec 2014 04:48:22 -0800 (PST) In-Reply-To: <8F3BDC42-83EE-46FA-AEFB-F35561290D48@gmail.com> References: <8F3BDC42-83EE-46FA-AEFB-F35561290D48@gmail.com> From: Jia-Shiun Li Date: Thu, 18 Dec 2014 20:48:22 +0800 Message-ID: Subject: Re: _bootstrap-tools parallel build (was: Re: CFR, CFT: Fine-grained SUBDIR dependencies for parallel builds To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ian Lepore , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 12:48:54 -0000 On Thu, Dec 18, 2014 at 3:49 AM, Garrett Cooper wro= te: > Hi Jia-Shiun! > I submitted the gnu/usr.bin/groff portion of your patch in r27586= 6 . I=E2=80=99m going to look at stripping down bootstrap-tools, et al a bi= t more in the next couple days and I=E2=80=99ll be using your patch in part= with some parallel efforts I=E2=80=99ve done on a branch on my github fork= as well: https://github.com/yaneurabeya/freebsd/tree/faster-build . > Thank you! Thank you! My makefile writing is not very fluent, yours looks much better than mine. ;) Look forward to your works. -Jia-Shiun From owner-freebsd-arch@FreeBSD.ORG Thu Dec 18 19:49:33 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42D1B5E5; Thu, 18 Dec 2014 19:49:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1AFFC1695; Thu, 18 Dec 2014 19:49:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 97EB0B945; Thu, 18 Dec 2014 14:49:31 -0500 (EST) From: John Baldwin To: "Poul-Henning Kamp" Subject: Re: Change default VFS timestamp precision? Date: Thu, 18 Dec 2014 14:36:31 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201412161348.41219.jhb@freebsd.org> <70449.1418843354@critter.freebsd.dk> In-Reply-To: <70449.1418843354@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412181436.31701.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Dec 2014 14:49:31 -0500 (EST) Cc: "freebsd-arch@freebsd.org" , Adrian Chadd , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:49:33 -0000 On Wednesday, December 17, 2014 2:09:14 pm Poul-Henning Kamp wrote: > -------- > In message > , Adrian Chadd writes: > > >> I think it is over 10 years ago when make(1) first started seeing > >> identical timestamps which wasn't. > >> > >> In most Makefiles this doesn't matter, but there are cases, in particular > >> in less integrated families of makefiles than our own. > > > >Surely there has to be better ways of doing this stuff. Computers keep > >getting faster; it wouldn't be out of the realm of possibility that we > >could see a compiler read, compile and spit out a .o inside of a > >millisecond. (Obviously not C++, but..) > > A millisecond is pushing it, all things considered, it would have to > be an utterly trivial source file for a utterly trivial language. > > Given that it has epsilon cost, switching to TSP_HZ should be a > no-brainer, I've been running that for ages. > > Why TSP_USEC exists is beyond me, it's slower and worse than TSP_NSEC. > > But going to TSP_NSEC by default seems unwarranted to me. Eh, the use case I most care about is back-to-back updates to a directory on an NFS server. Those can certainly occur quite quickly and in under a millisecond (e.g. rm foo* in a directory is going to be multiple unlink() calls each of which will update the mtime of the directory). I don't understand why you think TSP_USEC is slower than TSP_NSEC. microtime() and nanotime() both just call bintime() and then convert the result using similar math. However, I think I buy Jilles' argument that TSP_USEC is likely to give more stable results (i.e. increasing mtime) if back to back updates are performed across CPUs (assuming some amount of TSC jitter for example). -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Dec 18 20:05:08 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 677B3E2E; Thu, 18 Dec 2014 20:05:08 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 26CBC196E; Thu, 18 Dec 2014 20:05:07 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 76C383BD1A; Thu, 18 Dec 2014 20:05:01 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sBIK50ZE077323; Thu, 18 Dec 2014 20:05:00 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin Subject: Re: Change default VFS timestamp precision? In-reply-to: <201412181436.31701.jhb@freebsd.org> From: "Poul-Henning Kamp" References: <201412161348.41219.jhb@freebsd.org> <70449.1418843354@critter.freebsd.dk> <201412181436.31701.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77321.1418933100.1@critter.freebsd.dk> Date: Thu, 18 Dec 2014 20:05:00 +0000 Message-ID: <77322.1418933100@critter.freebsd.dk> Cc: "freebsd-arch@freebsd.org" , Adrian Chadd , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 20:05:08 -0000 -------- In message <201412181436.31701.jhb@freebsd.org>, John Baldwin writes: >> >Surely there has to be better ways of doing this stuff. Computers keep >> >getting faster; it wouldn't be out of the realm of possibility that we >> >could see a compiler read, compile and spit out a .o inside of a >> >millisecond. (Obviously not C++, but..) >> >> A millisecond is pushing it, all things considered, it would have to >> be an utterly trivial source file for a utterly trivial language. >Eh, the use case I most care about is back-to-back updates to a directory on >an NFS server. My comments above was only about compilers in reference to Adrians point. >I don't understand >why you think TSP_USEC is slower than TSP_NSEC. microtime() and nanotime() >both just call bintime() and then convert the result using similar math. Because of the pointless nano->micro conversion which makes TSP_USEC take a division longer to deliver a less precise result than TSP_NSEC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Thu Dec 18 20:14:05 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FA5218C; Thu, 18 Dec 2014 20:14:05 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E2C781ADC; Thu, 18 Dec 2014 20:14:04 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id B844A3BD1A; Thu, 18 Dec 2014 20:14:02 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sBIKE2DN077372; Thu, 18 Dec 2014 20:14:02 GMT (envelope-from phk@phk.freebsd.dk) Subject: Re: Change default VFS timestamp precision? In-reply-to: <77322.1418933100@critter.freebsd.dk> From: "Poul-Henning Kamp" References: <201412161348.41219.jhb@freebsd.org> <70449.1418843354@critter.freebsd.dk> <201412181436.31701.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77370.1418933642.1@critter.freebsd.dk> Date: Thu, 18 Dec 2014 20:14:02 +0000 Message-ID: <77371.1418933642@critter.freebsd.dk> Cc: "freebsd-arch@freebsd.org" , Adrian Chadd , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 20:14:05 -0000 -------- In message <77322.1418933100@critter.freebsd.dk>, "Poul-Henning Kamp" writes: >>I don't understand >>why you think TSP_USEC is slower than TSP_NSEC. microtime() and nanotime() >>both just call bintime() and then convert the result using similar math. > >Because of the pointless nano->micro conversion which makes TSP_USEC >take a division longer to deliver a less precise result than TSP_NSEC. Actually, that's the other way around: it converts microseconds to nanoseconds with a pointless multiplication. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Dec 19 14:50:52 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8537C833; Fri, 19 Dec 2014 14:50:52 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 25984307C; Fri, 19 Dec 2014 14:50:50 +0000 (UTC) Message-ID: <54943B2B.9000407@FreeBSD.org> Date: Fri, 19 Dec 2014 17:50:19 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC] add macros for ifnet statistic accounting References: <546E25D1.7020900@FreeBSD.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2q53MbB66jEuwLhXAgnSpjUvUk8hRlPPm" Cc: "freebsd-net@freebsd.org" , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 14:50:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2q53MbB66jEuwLhXAgnSpjUvUk8hRlPPm Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 20.11.2014 20:38, Adrian Chadd wrote: > On 20 November 2014 09:33, Andrey V. Elsukov wrote: >> Hi All, >> >> we already did some changes in network stack in head/, that made abili= ty >> for merging changes into stable branches much harder. >> >> What you think about adding the following macro to head/: >> >> --- if_var.h (revision 274736) >> +++ if_var.h (working copy) >> @@ -111,6 +111,10 @@ typedef enum { >> IFCOUNTERS /* Array size. */ >> } ift_counter; >> >> +#define IFSTAT_ADD(ifp, name, value) \ >> + if_inc_counter((ifp), IFCOUNTER_ ## name, (value)) >> +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) >> + >> typedef struct ifnet * if_t; >> >> typedef void (*if_start_fn_t)(if_t); >> >> >> And then make a direct commit to stable/* branches like this: >> >> --- if_var.h (revision 274750) >> +++ if_var.h (working copy) >> @@ -104,6 +104,23 @@ VNET_DECLARE(struct pfil_head, link_pfil_hook); = /* >> #define V_link_pfil_hook VNET(link_pfil_hook) >> #endif /* _KERNEL */ >> >> +#define IFSTAT_ADD(ifp, name, value) \ >> + IFSTAT_ ## name ## _ADD(ifp, value) >> +#define IFSTAT_INC(ifp, name) IFSTAT_ADD(ifp, name, 1) >> + >> +#define IFSTAT_IPACKETS_ADD(ifp, inc) (ifp)->if_ipackets +=3D= (inc) >> +#define IFSTAT_IERRORS_ADD(ifp, inc) (ifp)->if_ierrors +=3D= (inc) >> +#define IFSTAT_OPACKETS_ADD(ifp, inc) (ifp)->if_opackets +=3D= (inc) >> +#define IFSTAT_OERRORS_ADD(ifp, inc) (ifp)->if_oerrors +=3D= (inc) >> +#define IFSTAT_COLLISIONS_ADD(ifp, inc) (ifp)->if_collisions += =3D (inc) >> +#define IFSTAT_IBYTES_ADD(ifp, inc) (ifp)->if_ibytes +=3D = (inc) >> +#define IFSTAT_OBYTES_ADD(ifp, inc) (ifp)->if_obytes +=3D = (inc) >> +#define IFSTAT_IMCASTS_ADD(ifp, inc) (ifp)->if_imcasts +=3D= (inc) >> +#define IFSTAT_OMCASTS_ADD(ifp, inc) (ifp)->if_omcasts +=3D= (inc) >> +#define IFSTAT_IQDROPS_ADD(ifp, inc) (ifp)->if_iqdrops +=3D= (inc) >> +#define IFSTAT_OQDROPS_ADD(ifp, inc) /* NOP */ >> +#define IFSTAT_NOPROTO_ADD(ifp, inc) (ifp)->if_noproto +=3D= (inc) >> + >> /* >> * Structure defining a queue for a network interface. >> */ >> >> This can make merging a little bit easier, at least for generic code i= n >> the network stack. It looks there are not so much people, who wants this feature. We discussed this with glebius@ and probably the better solution will be merging ift_counter enum and adding if_inc_counter() function to stable/10. I looked how other BSDs doing this accounting and only DfBSD has macro IFNET_STAT_INC(). But since we are planning to make opaque ifnet, it doesn't matter how we will do accounting, anyway it will be incompatible with other BSDs. If there is no objections I'll commit this after weekend. Index: if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if.c (revision 275939) +++ if.c (working copy) @@ -1450,6 +1450,56 @@ if_rtdel(struct radix_node *rn, void *arg) } /* + * A compatibility function returns ifnet counter values. + */ +uint64_t +if_get_counter_default(struct ifnet *ifp, ift_counter cnt) +{ + + KASSERT(cnt < IFCOUNTERS, ("%s: invalid cnt %d", __func__, cnt)); + + switch (cnt) { + case IFCOUNTER_IPACKETS: return (ifp->if_ipackets); + case IFCOUNTER_IERRORS: return (ifp->if_ierrors); + case IFCOUNTER_OPACKETS: return (ifp->if_opackets); + case IFCOUNTER_OERRORS: return (ifp->if_oerrors); + case IFCOUNTER_COLLISIONS: return (ifp->if_collisions); + case IFCOUNTER_IBYTES: return (ifp->if_ibytes); + case IFCOUNTER_OBYTES: return (ifp->if_obytes); + case IFCOUNTER_IMCASTS: return (ifp->if_imcasts); + case IFCOUNTER_OMCASTS: return (ifp->if_omcasts); + case IFCOUNTER_IQDROPS: return (ifp->if_iqdrops); + case IFCOUNTER_NOPROTO: return (ifp->if_noproto); + }; + return (0); +} + +/* + * Increase an ifnet counter. Usually used for counters shared + * between the stack and a driver, but function supports them all. + */ +void +if_inc_counter(struct ifnet *ifp, ift_counter cnt, int64_t inc) +{ + + KASSERT(cnt < IFCOUNTERS, ("%s: invalid cnt %d", __func__, cnt)); + + switch (cnt) { + case IFCOUNTER_IPACKETS: ifp->if_ipackets +=3D inc; break; + case IFCOUNTER_IERRORS: ifp->if_ierrors +=3D inc; break; + case IFCOUNTER_OPACKETS: ifp->if_opackets +=3D inc; break; + case IFCOUNTER_OERRORS: ifp->if_oerrors +=3D inc; break; + case IFCOUNTER_COLLISIONS: ifp->if_collisions +=3D inc; break; + case IFCOUNTER_IBYTES: ifp->if_ibytes +=3D inc; break; + case IFCOUNTER_OBYTES: ifp->if_obytes +=3D inc; break; + case IFCOUNTER_IMCASTS: ifp->if_imcasts +=3D inc; break; + case IFCOUNTER_OMCASTS: ifp->if_omcasts +=3D inc; break; + case IFCOUNTER_IQDROPS: ifp->if_iqdrops +=3D inc; break; + case IFCOUNTER_NOPROTO: ifp->if_noproto +=3D inc; break; + }; +} + +/* * Wrapper functions for struct ifnet address list locking macros. These are * used by kernel modules to avoid encoding programming interface or bin= ary * interface assumptions that may be violated when kernel-internal locki= ng Index: if_var.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_var.h (revision 275939) +++ if_var.h (working copy) @@ -104,6 +104,22 @@ VNET_DECLARE(struct pfil_head, link_pfil_hook); /* #define V_link_pfil_hook VNET(link_pfil_hook) #endif /* _KERNEL */ +typedef enum { + IFCOUNTER_IPACKETS =3D 0, + IFCOUNTER_IERRORS, + IFCOUNTER_OPACKETS, + IFCOUNTER_OERRORS, + IFCOUNTER_COLLISIONS, + IFCOUNTER_IBYTES, + IFCOUNTER_OBYTES, + IFCOUNTER_IMCASTS, + IFCOUNTER_OMCASTS, + IFCOUNTER_IQDROPS, + IFCOUNTER_OQDROPS, + IFCOUNTER_NOPROTO, + IFCOUNTERS /* Array size. */ +} ift_counter; + /* * Structure defining a queue for a network interface. */ @@ -981,6 +997,8 @@ typedef void *if_com_alloc_t(u_char type, struct i typedef void if_com_free_t(void *com, u_char type); void if_register_com_alloc(u_char type, if_com_alloc_t *a, if_com_free_t *f); void if_deregister_com_alloc(u_char type); +uint64_t if_get_counter_default(struct ifnet *, ift_counter); +void if_inc_counter(struct ifnet *, ift_counter, int64_t); #define IF_LLADDR(ifp) \ LLADDR((struct sockaddr_dl *)((ifp)->if_addr->ifa_addr)) --=20 WBR, Andrey V. Elsukov --2q53MbB66jEuwLhXAgnSpjUvUk8hRlPPm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUlDsyAAoJEAHF6gQQyKF64gYH/3sfTX6mrhxU+4nUsT70GaOe Es7sl+RKJgaf7Orz72IngTbFSP5Glq0huTriznGPC49PoZKIFeq0G/v7GuZLd+hC WUDcJLKHHCPQ4LG5KC5vTi7krnnoh+IufDRTF4c4eytpQT76TVaeUTDCv/nWYzFY sgGFBsUV8UeaWBwcPsOY25BfwMWi8Ige2dXB+4JIEZUTmRJ3ljOVe0coUKBsqffm 5nk7xpk0n9Sk8IS4ROQsElqRkfDXuHcbhm/06zH1TupXtFjzx6ypmw0o3PzsLjMe ozB9HLy3cwh9fKC7eT0jsQbuJTzLarstGko+VeyPadvTnWgA37Rcxz4Vu7y2w/w= =nUTn -----END PGP SIGNATURE----- --2q53MbB66jEuwLhXAgnSpjUvUk8hRlPPm-- From owner-freebsd-arch@FreeBSD.ORG Fri Dec 19 17:28:10 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 618D0B60; Fri, 19 Dec 2014 17:28:10 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3AF1A22AB; Fri, 19 Dec 2014 17:28:10 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BC505B97F; Fri, 19 Dec 2014 12:28:08 -0500 (EST) From: John Baldwin To: Poul-Henning Kamp Subject: Re: Change default VFS timestamp precision? Date: Fri, 19 Dec 2014 10:28:02 -0500 Message-ID: <7567696.mqJ3jgzJgL@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <77371.1418933642@critter.freebsd.dk> References: <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Dec 2014 12:28:08 -0500 (EST) Cc: "freebsd-arch@freebsd.org" , Adrian Chadd , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 17:28:10 -0000 On Thursday, December 18, 2014 08:14:02 PM Poul-Henning Kamp wrote: > -------- > > In message <77322.1418933100@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > >>I don't understand > >>why you think TSP_USEC is slower than TSP_NSEC. microtime() and > >>nanotime() > >>both just call bintime() and then convert the result using similar math. > > > >Because of the pointless nano->micro conversion which makes TSP_USEC > >take a division longer to deliver a less precise result than TSP_NSEC. > > Actually, that's the other way around: it converts microseconds to > nanoseconds with a pointless multiplication. Yes, and multiplication is cheaper than division. It's not a power of two (so more than a single bitshift), but possibly in the noise compared to the work in bintime() itself. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Dec 19 17:41:05 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB4A9ECC; Fri, 19 Dec 2014 17:41:05 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3942592; Fri, 19 Dec 2014 17:41:04 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0C4243BD1A; Fri, 19 Dec 2014 17:41:02 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sBJHf12e082136; Fri, 19 Dec 2014 17:41:01 GMT (envelope-from phk@phk.freebsd.dk) To: John Baldwin Subject: Re: Change default VFS timestamp precision? In-reply-to: <7567696.mqJ3jgzJgL@ralph.baldwin.cx> From: "Poul-Henning Kamp" References: <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> <7567696.mqJ3jgzJgL@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82134.1419010861.1@critter.freebsd.dk> Date: Fri, 19 Dec 2014 17:41:01 +0000 Message-ID: <82135.1419010861@critter.freebsd.dk> Cc: "freebsd-arch@freebsd.org" , Adrian Chadd , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 17:41:05 -0000 -------- In message <7567696.mqJ3jgzJgL@ralph.baldwin.cx>, John Baldwin writes: >Yes, and multiplication is cheaper than division. It's not a power of >two (so more than a single bitshift), but possibly in the noise compared >to the work in bintime() itself. But why not use nanosecond resolution given that the cost is cheaper ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Dec 19 19:48:04 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03B9C3C9; Fri, 19 Dec 2014 19:48:04 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BB7361C86; Fri, 19 Dec 2014 19:48:03 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id ACAB3B80AD; Fri, 19 Dec 2014 20:48:00 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 9A7F228494; Fri, 19 Dec 2014 20:48:00 +0100 (CET) Date: Fri, 19 Dec 2014 20:48:00 +0100 From: Jilles Tjoelker To: Poul-Henning Kamp Subject: Re: Change default VFS timestamp precision? Message-ID: <20141219194800.GA29107@stack.nl> References: <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> <7567696.mqJ3jgzJgL@ralph.baldwin.cx> <82135.1419010861@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82135.1419010861@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-arch@freebsd.org" , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 19:48:04 -0000 On Fri, Dec 19, 2014 at 05:41:01PM +0000, Poul-Henning Kamp wrote: > In message <7567696.mqJ3jgzJgL@ralph.baldwin.cx>, John Baldwin writes: > >Yes, and multiplication is cheaper than division. It's not a power of > >two (so more than a single bitshift), but possibly in the noise compared > >to the work in bintime() itself. > But why not use nanosecond resolution given that the cost is cheaper ? Because there is no API to set timestamps with nanosecond resolution, and therefore a cp -p copy of a file will appear older than the original with 99.9% probability. I think that is undesirable. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Fri Dec 19 19:49:32 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FA7448B; Fri, 19 Dec 2014 19:49:32 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 209EC1C9E; Fri, 19 Dec 2014 19:49:31 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id CA1073BD1A; Fri, 19 Dec 2014 19:49:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sBJJnSMe082508; Fri, 19 Dec 2014 19:49:29 GMT (envelope-from phk@phk.freebsd.dk) To: Jilles Tjoelker Subject: Re: Change default VFS timestamp precision? In-reply-to: <20141219194800.GA29107@stack.nl> From: "Poul-Henning Kamp" References: <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> <7567696.mqJ3jgzJgL@ralph.baldwin.cx> <82135.1419010861@critter.freebsd.dk> <20141219194800.GA29107@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82506.1419018568.1@critter.freebsd.dk> Date: Fri, 19 Dec 2014 19:49:28 +0000 Message-ID: <82507.1419018568@critter.freebsd.dk> Cc: "freebsd-arch@freebsd.org" , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 19:49:32 -0000 -------- In message <20141219194800.GA29107@stack.nl>, Jilles Tjoelker writes: >On Fri, Dec 19, 2014 at 05:41:01PM +0000, Poul-Henning Kamp wrote: >> In message <7567696.mqJ3jgzJgL@ralph.baldwin.cx>, John Baldwin writes: > >> >Yes, and multiplication is cheaper than division. It's not a power of >> >two (so more than a single bitshift), but possibly in the noise compared >> >to the work in bintime() itself. > >> But why not use nanosecond resolution given that the cost is cheaper ? > >Because there is no API to set timestamps with nanosecond resolution, >and therefore a cp -p copy of a file will appear older than the original >with 99.9% probability. I think that is undesirable. Hmm, good point, I forgot about that screwup... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Dec 19 20:12:06 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 926BC8F4 for ; Fri, 19 Dec 2014 20:12:06 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E8232126 for ; Fri, 19 Dec 2014 20:12:06 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id sBJKC2Lu086110; Fri, 19 Dec 2014 15:12:03 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id sBJKC1rW086109; Fri, 19 Dec 2014 15:12:01 -0500 (EST) (envelope-from wollman) Date: Fri, 19 Dec 2014 15:12:01 -0500 (EST) From: Garrett Wollman Message-Id: <201412192012.sBJKC1rW086109@hergotha.csail.mit.edu> To: jilles@stack.nl Subject: Re: Change default VFS timestamp precision? X-Newsgroups: mit.lcs.mail.freebsd-arch References: <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> <7567696.mqJ3jgzJgL@ralph.baldwin.cx> <82135.1419010861@critter.freebsd.dk> <20141219194800.GA29107@stack.nl> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Fri, 19 Dec 2014 15:12:03 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 20:12:06 -0000 In article <20141219194800.GA29107@stack.nl>, jilles@stack.nl writes: >Because there is no API to set timestamps with nanosecond resolution, >and therefore a cp -p copy of a file will appear older than the original >with 99.9% probability. I think that is undesirable. But that's something we can easily fix -- and should have done, years ago. Why don't we just *do* that? Of course, in the case of NFS clients, where this issue is most severe, the RPCs are already defined. The underlying VOP_SETATTR has no trouble with nanoseconds, either. It's just a matter of providing a standard library interface (and associated system call(s)) to do it, and since Linux has already implemented this, we can just implement that interface and applications will get it "for free". -GAWollman