From owner-svn-src-head@FreeBSD.ORG Wed Jan 21 23:38:48 2015 Return-Path: Delivered-To: svn-src-head@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 C8C98C19; Wed, 21 Jan 2015 23:38:48 +0000 (UTC) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 8070C6A; Wed, 21 Jan 2015 23:38:48 +0000 (UTC) Received: by mail-yk0-f174.google.com with SMTP id 131so8517013ykp.5; Wed, 21 Jan 2015 15:38:47 -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=8OMk8ZyDfJ5iO/5a42lN/FX2AkyFpSu+phMwURKEdEs=; b=WAsICYQVdpdartmx30WHMILlMN8OdxxEwLIBIsvbre2Vs4EV5x0OSKwaNvGK2lPXLe SIx1+zLlIArAKY9XOqeA11wbswRAC/6fVQ+E0uaML51h3AnZ3JfG906ijf1nIDqsuzKM gDi6E+rSRk/668ou69Smq8zIAR70T2vf4aUkLAurHmOee4hbN6uOr3k7GdTKJoWpM7BC tEsLV/iFMRkr253ITqTlD4emmdjjYU1UYQB8oP2N8kLtizZ3Oa7Yd6fcMVmkkSYFtSVi xuUP0iTmV48fkErLsLCSpHCGYVvzHJGLDujSq2CeluQRP22oW00MHkHTT4oUGeOyTA1I BJcw== MIME-Version: 1.0 X-Received: by 10.170.44.4 with SMTP id 4mr5972319ykm.101.1421883527531; Wed, 21 Jan 2015 15:38:47 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.70.132 with HTTP; Wed, 21 Jan 2015 15:38:47 -0800 (PST) In-Reply-To: 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> Date: Wed, 21 Jan 2015 15:38:47 -0800 X-Google-Sender-Auth: vW1M_N2egVIk1Uym597yF86LjyU Message-ID: Subject: Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys From: "K. Macy" To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: Hans Petter Selasky , "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: Wed, 21 Jan 2015 23:38:48 -0000 > They originally found that things were spinning for way too long. > > 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. > > I don't think it's as alchemic as is being promoted. 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. 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. 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. 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. 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. 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. Thanks in advance. -K