From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A713C433EF for ; Tue, 7 Dec 2021 17:07:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C77D86B00BB; Tue, 7 Dec 2021 12:07:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C01146B00BC; Tue, 7 Dec 2021 12:07:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA2106B00BD; Tue, 7 Dec 2021 12:07:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) by kanga.kvack.org (Postfix) with ESMTP id 9444A6B00BB for ; Tue, 7 Dec 2021 12:07:19 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 56DA51814758D for ; Tue, 7 Dec 2021 17:07:09 +0000 (UTC) X-FDA: 78891628578.16.E6CB671 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf18.hostedemail.com (Postfix) with ESMTP id A0A73400208A for ; Tue, 7 Dec 2021 17:07:08 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 7D67DCE1B21; Tue, 7 Dec 2021 17:07:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52B98C341C3; Tue, 7 Dec 2021 17:07:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638896822; bh=ZB2ALhaSGs3qcTtFma/ISGlGvE0OkTJEIiqd6ggTHGY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OBdVVydQHbzCRsH8h2bwy/L6iQ7lHRMZL7T+drJqOHfk+8wh1WFlaEj6rpycQZj7l TgqGHPWOqTly0vhl3YnycmFvx20pGnbV/eSrRPkfAVhZdxeFhDXEkk5g50ZoqCz7qN G0yn0DO+JINokjs0ajF6MkPDhtzxgpm55j9M3i/xbh3DKqYv5nMPTMSMhW6I+rclV7 R6qAv6mF9SDu1OCmr6CAtiwe1W+8R7yeUe6ZAwX3m2sN9rBIYoTc1qSYErl9s78Re6 BgciwZet95O8OjXnNGjfjWOl/H4p44mFtwxxiQcvlh10v5SNh49pAEt3KnLYDhuJ8P 5fb0JoIjUmeiQ== Date: Tue, 7 Dec 2021 09:07:00 -0800 From: Jakub Kicinski To: Justin Iurman Cc: netdev@vger.kernel.org, davem@davemloft.net, dsahern@kernel.org, yoshfuji@linux-ipv6.org, linux-mm@kvack.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo kim , akpm@linux-foundation.org, vbabka@suse.cz Subject: Re: [RFC net-next 2/2] ipv6: ioam: Support for Buffer occupancy data field Message-ID: <20211207090700.55725775@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: <1045511371.220520131.1638894949373.JavaMail.zimbra@uliege.be> References: <20211206211758.19057-1-justin.iurman@uliege.be> <20211206211758.19057-3-justin.iurman@uliege.be> <20211206161625.55a112bb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <262812089.220024115.1638878044162.JavaMail.zimbra@uliege.be> <20211207075037.6cda8832@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <1045511371.220520131.1638894949373.JavaMail.zimbra@uliege.be> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A0A73400208A X-Stat-Signature: gn95iu7i86hm7urhi1cx6rjbrrxdmw5r Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OBdVVydQ; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of kuba@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=kuba@kernel.org X-HE-Tag: 1638896828-407135 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 7 Dec 2021 17:35:49 +0100 (CET) Justin Iurman wrote: > > provides the best signal. Since the slab cache scales dynamically > > (AFAIU) it's not really a big deal if it's full as long as there's > > memory available on the system. > > Well, I got the same understanding as you. However, we do not provide a > value meaning "X percent used" just because it wouldn't make much sense, > as you pointed out. So I think it is sound to have the current value, > even if it's a quite dynamic one. Indeed, what's important here is to > know how many bytes are used and this is exactly what it does. If a node > is under heavy load, the value would be hell high. The operator could > define a threshold for each node resp. and detect abnormal values. Hm, reading thru the quoted portion of the standard from the commit message the semantics of the field are indeed pretty disappointing. What's the value of defining a field in a standard if it's entirely implementation specific? Eh. > We probably want the metadata included for accuracy as well (e.g., > kmem_cache_size vs new function kmem_cache_full_size). Does the standard support carrying arbitrary metadata? Anyway, in general I personally don't have a good feeling about implementing this field. Would be good to have a clear user who can justify the choice of slab vs something else. Wouldn't modern deployments use some form of streaming telemetry for nodes within the same domain of control? I'm not sure I understand the value of limited slab info in OAM when there's probably a more powerful metric collection going on. Patch 1 makes perfect sense, FWIW.