From owner-svn-src-head@FreeBSD.ORG Thu Jan 22 00:02:24 2015 Return-Path: Delivered-To: svn-src-head@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 896061E1 for ; Thu, 22 Jan 2015 00:02:24 +0000 (UTC) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (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 4FFCB366 for ; Thu, 22 Jan 2015 00:02:24 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id ey11so4382307pad.7 for ; Wed, 21 Jan 2015 16:02:17 -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:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=pj+XAipv+1zDq0JT5C57Pi51xsjzZwF2Z0ubn1i6TkM=; b=mbTelq5oyl1yQdyCtPrXxPgiv37nSSZGeiL6aLNANZTKsKpJvXi+DG4Azrpv6b4kin +UdAOX/Aq7MxboyGpYTutsO1g00ALF2UIGpNnSuAlQ8HMrwr9Cmo9fVSkO0XQKOGXtHK 0L23NeDEGUmY3JWgHQyCb7CyiXrgSzHp1uxoRGtLsXDoFI5fNimVC2aK/vmI5egxqfI6 ZfT4gKKxJ7pagO5cjlz976SkqogtwGdJLbifDPW3wPmwynSiZ6+UMPL32SRxIO6vqAZ+ NoDp/gOCtAdCHzeCQSaaiAcxdQJbsLT7uVnNi6Wo9coWWU0bw7WiV871qLiSSgJq3nnt IeNw== X-Gm-Message-State: ALoCoQkVm7NSg5ZO+9ucQxYt6yQjzIGaR92LOYqTA5zfK7wo4H0RTIDzfr5MAX9aB+clt+dO7EuJ X-Received: by 10.70.46.69 with SMTP id t5mr32605830pdm.167.1421884937743; Wed, 21 Jan 2015 16:02:17 -0800 (PST) Received: from bsdimp.corp.netflix.com ([69.53.237.72]) by mx.google.com with ESMTPSA id zk9sm7410858pac.1.2015.01.21.16.02.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 16:02:17 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys From: Warner Losh In-Reply-To: Date: Wed, 21 Jan 2015 17:02:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150120075126.GA42409@kib.kiev.ua> <20150120211137.GY15484@FreeBSD.org> <54BED6FB.8060401@selasky.org> <54BEE62D.2060703@ignoranthack.me> <54BEE8E6.3080009@ignoranthack.me> <54BEEA7F.1070301@ignoranthack.me> <54BEF154.3030606@ignoranthack.me> <20150121181512.GE15484@FreeBSD.org> To: "K. Macy" X-Mailer: Apple Mail (2.1993) X-Mailman-Approved-At: Thu, 22 Jan 2015 00:05:04 +0000 Cc: Hans Petter Selasky , Adrian Chadd , "src-committers@freebsd.org" , Jason Wolfe , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , Sean Bruno , Gleb Smirnoff , Konstantin Belousov X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 00:02:24 -0000 > On Jan 21, 2015, at 4:38 PM, K. Macy wrote: >=20 >> They originally found that things were spinning for way too long. >>=20 >> Hans found something similar and determined/concluded that the >> migration code in callouts was racy-by-design and dramatically >> simplified it and also put very hard constraints on what is a valid >> situation to support migrating from one callwheel to another. Now we >> have fallout which we can either address or back out until the = callout >> stuff is again reviewed/fixed. >>=20 >> I don't think it's as alchemic as is being promoted. >=20 >=20 > Let's not get drawn into semantic debates. To me alchemy implies > voodoo debugging, whereas this is, in part, disabling functionality > that exposes races - which is more like disabling preemption or fine > grained locking. >=20 >=20 > Normally I would advocate backing this out on the basis of precedence. > That is to say, back it out so that developers will get it right the > first time. However, it appears that hps@ and some others don't > understand what was done wrong. So I'm going to state some basic > premises and then the implied basic guidelines required of a commit > that were not met. If these guidelines are violated by a change in the > future I will agitate for a rapid back out. >=20 > Premises: > A) A performance regression is a bug every bit as much as a locking > race. Stability OR performance (where we are talking about _current_ > performance) is a false dichotomy. > - This means that a change that fixes a bug by introducing a > substantial performance regression does not constitute a fix. > B) Existing behavior and performance characteristics should not be > adversely changed unless there is widespread consensus. > - Sometimes it is necessary to "break" a KPI but that should not be > discovered by svn or scanning back through the mailing lists. >=20 > Guidelines: > A) Performance should not measurably regress. > B) If a KPI changes behavior e.g. callout_reset_on being crippled, all > clients need to be updated so that they maintain their current > behavior by the committer changing the KPI. The client code > maintainers aren't responsible for reacting to these types of changes. > That is OK for marginal architectures like sun4v or pc98. > C) If there is a non-zero possibility that these changes break the > client code, committers who have touched that code in the last few > years should be notified. >=20 >=20 >=20 > HPS: Your change failed to meet these guidelines. Some of us are upset > because these guidelines are fairly fundamental for the on-going > viability of FreeBSD. Due to linguistic / time zone / cultural > differences these expectations have not been adequately communicated > to you. You are not in the USB sandbox where others need for your > support outweighs the inconvenience of random breakage. >=20 > It sounds like you are making progress towards updating the concerns > that have been voiced. If kib's observations are in fact comprehensive > then adding a callout_init_cpu function and updating all clients so > that their callouts continue to be scheduled on a CPU other than the > BSP will suffice and we can all move on. Is there some reason that we can=E2=80=99t back things out, break things = down into smaller pieces and have everything pass through phabric with a wide ranging review? Given the fundamental nature of these changes, they really need better review and doing it after the fact seems to be to be too risky. I=E2=80=99m not debating that this =E2=80=9Cfixes=E2=80=9D = some issues, but given the performance regression, it sure seems like we may need a different solution to be implemented and hashing that out in a branch might be the best approach. Warner=