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 3A00CC433F5 for ; Mon, 10 Jan 2022 08:11:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 621056B009F; Mon, 10 Jan 2022 03:11:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D1436B00A0; Mon, 10 Jan 2022 03:11:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 498FB6B00A1; Mon, 10 Jan 2022 03:11:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id 3A5646B009F for ; Mon, 10 Jan 2022 03:11:26 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DF7A3181C98EA for ; Mon, 10 Jan 2022 08:11:25 +0000 (UTC) X-FDA: 79013657730.04.D4E147D Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf16.hostedemail.com (Postfix) with ESMTP id 877E718000A for ; Mon, 10 Jan 2022 08:11:25 +0000 (UTC) Received: by mail-lf1-f49.google.com with SMTP id m1so8182425lfq.4 for ; Mon, 10 Jan 2022 00:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+MlSZiq9RqylWqDh0sRZineCftjbqoTJy5wCtgk/PXk=; b=lKs1E7vhWP22buArl+muj6kwVzs6P90Xz+OW+m5epbct4jtpfJmTrAwey0yQvMtz+b +NPW9kec6s2A0PCpVh4kNBEZwSHvkth+HT9iiCdRewCko1pQvoq3bzkKRTGVx0QF+lNF YCrNTK4UowVvsIITmc30TChYZ/lbq65CeSPIG+x/icbAA4bt97oK1DCGbLklA7+YkUxI l4qBWrzjLe5UBNPryO4vlnltEiHcSoS2GfvfK8werJztcC6KKau4cqFxoD0884Nz5uHV hGi80jYoD/ukwzyRhKw7twvz06zOQ9QXokpLOJGkRaJQRptCX+ZTQJAHMPv19mgCdGKs Kong== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+MlSZiq9RqylWqDh0sRZineCftjbqoTJy5wCtgk/PXk=; b=rbBcQByG7zNWYarCl7P/JW26F4TmA+kPcMHJNtuJSLAT811nTPlS1YWAISNSTK0bnv gU+TR3ksRoaIVVrUqB2jS3vlV++rH6SfsFygXRaKc4xAqxDm17v1GJ8LMdukrxWARhLA Ibydcn7/ABAKUSec3rjBg15n5VkJLjCyNBSNtu6NuKSNlCPPoYT16jvoz82NBG3EMXwx aJHQUQFHAY63K5nJCy7kvXRneUYzZ3gtPKA55bbo01ut+Ct5WEVgCnPj2bzAF+QXMN0T HyYuFtWH4MCwPVAx3LCHgaKjqxaFWQvT/WfeA94/uMLGdak/JcllVGz4Xdn+mz90zL07 SDXQ== X-Gm-Message-State: AOAM531XY3H7fd2HAFL+GfUuDsjAsxGByMN2xAeF0XoPMKP6XZ+b2h74 bhr9qL0kCS2f76K9NzZ7Vy8= X-Google-Smtp-Source: ABdhPJyvAK15Ft/TN00MXnX0QnPG8re5XR1Yf1yQQ2tWZqRZdFUQ2pjijp4dqVOXxkvwbc/sD+nIew== X-Received: by 2002:a05:6512:130b:: with SMTP id x11mr33805576lfu.660.1641802283674; Mon, 10 Jan 2022 00:11:23 -0800 (PST) Received: from grain.localdomain ([5.18.251.97]) by smtp.gmail.com with ESMTPSA id w7sm950690lfd.36.2022.01.10.00.11.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 00:11:22 -0800 (PST) Received: by grain.localdomain (Postfix, from userid 1000) id 7B2335A0020; Mon, 10 Jan 2022 11:11:21 +0300 (MSK) Date: Mon, 10 Jan 2022 11:11:21 +0300 From: Cyrill Gorcunov To: Pintu Agarwal Cc: Pintu Kumar , open list , Andrew Morton , linux-mm , ebiederm@xmission.com, Christian Brauner , sfr@canb.auug.org.au, legion@kernel.org, sashal@kernel.org, chris.hyser@oracle.com, Colin Cross , Peter Collingbourne , dave@stgolabs.net, caoxiaofeng@yulong.com, david@redhat.com, Vlastimil Babka , linux-api@vger.kernel.org Subject: Re: [PATCH v2] sysinfo: include availram field in sysinfo struct Message-ID: References: <1641483250-18839-1-git-send-email-quic_pintu@quicinc.com> <1641578854-14232-1-git-send-email-quic_pintu@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lKs1E7vh; spf=pass (imf16.hostedemail.com: domain of gorcunov@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=gorcunov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 877E718000A X-Stat-Signature: sso7g79n4kfz6roc8k5qf8nkoch7k3j8 X-HE-Tag: 1641802285-542285 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 Sat, Jan 08, 2022 at 09:54:37PM +0530, Pintu Agarwal wrote: > Thank you so much for your feedback... > I had a need to get total/free/available memory in my application (on > a memory constraint system). > First I tried to parse these from /proc/meminfo but then I saw sysinfo > already provides some information, > however available field was missing. Just to get available field I > need to again do all the file operations. > > Then I saw, even the "free" command doing this redundant work. > Use sysinfo system call to get "total" and "free" memory then again > get "available" memory from /proc/meminfo. > Yet again, I see, even in kernel its reading from two different places > while populating the /proc/meminfo. > Also, I am sure there are plenty of other applications where this can > be improved with this. > Moreover, I think with this field there is not much use of other ram > fields in sysinfo. > Thus I felt a need to introduce this field to ease some operations. Thanks for explanation. > > > Don't get me wrong please but such extension really need a strong > > justification because they are part of UAPI and there is not that much > > space left in sysinfo structure. We will _have_ to live with this new > > field forever so I propose to not introduce anything new here until > > we have no other choise or parsing meminfo become a really bottleneck. > > > My guess is that this situation might exist in other places as well ? > How do we handle new field addition to existing system calls ? If there is no space left in uapi structures then we simply can't extend the syscall, since we're not allowed to break api. an option is to deprecate old interface and introduce a new one but this is a painfull procedure that's why i'm not convinced that we should extend sysinfo right now. but final decision is up to mantainers of course.