From owner-svn-src-head@freebsd.org Fri Sep 22 13:25:08 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62001E28E69; Fri, 22 Sep 2017 13:25:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 18AD16BF9A; Fri, 22 Sep 2017 13:25:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x232.google.com with SMTP id s18so1008370qta.3; Fri, 22 Sep 2017 06:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tc3VNbaeMXlxgNmxR6ZItJrIK+UiVcVUCfMWLNna6ZU=; b=A32T4dyDprq5aHZaYW/k0Rmt9IUHS3eeuufRu18wDMYVtDMrFrgCvPz5Q23/OsRuYX ELuTJAHcjWnubaQeoZkvEd3VZIa5ltjIGEn8bEuw8rwsJGhZmguw5vCTVrdKMKutCBsO io+qvigzDY5CYUUbLtPJudltbIiH9Xwdy1HMzpRQDUsJ18crGnvSSz/5ZLcKYy8yNTx0 13VtCfsTv+dkLfL3mpq2zImJnpW3BanCqtHcOk7Gu/70LNTaUommlmD19o9ct4cwj7P0 l5ZFEez7nSDXUeAkAu4eGxzpsEsWjSq1k85vkuuOqopb8yJ4Qc3qgZ+np3291lJNeneC evqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tc3VNbaeMXlxgNmxR6ZItJrIK+UiVcVUCfMWLNna6ZU=; b=WicaDZTFaa4T2Zcl5Np+RGGFuMK2WVqo4z/QfWp0FRG4hiwiQbZxWY5htHpi6dOQkH zMowvhN7O9YtpcqOBFrsJzZn4UnDoIRMCwpacUldXoHIRO9vNJTPtO8dXwhQFvDA8ELT Xlfm684ZzIgn4XhotxpZa6lirnV43QNUQY8E6U1X1Au794Njw2Vuh/dTDTH0XJ+9nta0 92Oy6hNCuyePGOuB372KHssM01PiKTItykWSr6JX1epXB695WfFLuTVGPg2QhAVOWOkD mJDAxJYHSSDSwIWzMNiJJ/p1JMWFRk4LOJ1584sFq6QCALeazMdJjOsvNAtezDBmHLGc tbFg== X-Gm-Message-State: AHPjjUhP8mhjYm+VpCsK7mfAHGbDavGj4Sic9HSPIwEKh8pVlNj0rPfu njvcxqJt8vnlXO/OR6/K8uqQNeustZahg8yUKkc= X-Google-Smtp-Source: AOwi7QDsDpsETDhRtQA6ROE33ACc+An6hdWKuyoyHQO5D0zP1EaWgp+k4QTxVUMqFgIrAZZ1e1/3JSCL7w3YiUxhoQQ= X-Received: by 10.200.26.211 with SMTP id h19mr8278714qtk.341.1506086707093; Fri, 22 Sep 2017 06:25:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.63.54 with HTTP; Fri, 22 Sep 2017 06:25:06 -0700 (PDT) In-Reply-To: <20170913223231.GN1055@FreeBSD.org> References: <201709101900.v8AJ0c2N059845@repo.freebsd.org> <20170911111127.B870@besplex.bde.org> <20170913223231.GN1055@FreeBSD.org> From: Mateusz Guzik Date: Fri, 22 Sep 2017 15:25:06 +0200 Message-ID: Subject: Re: svn commit: r323393 - in head/sys: sys vm To: Gleb Smirnoff Cc: Bruce Evans , Mateusz Guzik , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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: Fri, 22 Sep 2017 13:25:08 -0000 On Thu, Sep 14, 2017 at 12:32 AM, Gleb Smirnoff wrote: > On Mon, Sep 11, 2017 at 09:30:10AM +0200, Mateusz Guzik wrote: > M> First, there is a bunch of counter(9) fields. I don't know the original > M> reasoning. I would expect these counters to be statically defined in a > M> per-cpu struct. > > The reasoning was to remove 'struct vmmeter' from the 'struct pcpu', which > sounds inline with your desire to remote struct vmmeter from the kernel > at all. > > Maintainance wise, it is much easier not to bloat 'struct pcpu' with > various global statistics, but keep them as counter(9)s instead. Indeed, > what's the big difference between TCP statistics and VM statistics, why > treat them differently? > > Performance wise, I haven't seen any regressions when collapsed > multiple entities of struct vmmeter sitting in struct pcpu, into > single one with counter(9)s. > My general point is that low-level primitives are weirdly heavier than they need to be. Notable example is critical_enter/exit which are both function calls. As for counter(9), it adds an avoidable read. You are not going to measure the impact as it is due to the kernel being rather pessimized in general. pmc will probably show slight increase in cache misses, but that's it. That said, if maintenance is easier (I don't see why though) that's fine, I'm definitely not interested in fighting over this one. -- Mateusz Guzik