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 26E16C433F5 for ; Sat, 8 Jan 2022 16:24:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5ECDE6B0072; Sat, 8 Jan 2022 11:24:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59B5C6B0073; Sat, 8 Jan 2022 11:24:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 48A3E6B0074; Sat, 8 Jan 2022 11:24:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id 39D246B0072 for ; Sat, 8 Jan 2022 11:24:50 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D775D92DF8 for ; Sat, 8 Jan 2022 16:24:49 +0000 (UTC) X-FDA: 79007643498.21.F0F5280 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf21.hostedemail.com (Postfix) with ESMTP id 884AF1C000D for ; Sat, 8 Jan 2022 16:24:49 +0000 (UTC) Received: by mail-yb1-f178.google.com with SMTP id g80so26089613ybf.0 for ; Sat, 08 Jan 2022 08:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FJiGba+y5KGrEUxQgPj+i1n6kxwf6tPsHxl5ZtLV1Jk=; b=Er0wHgv/5O39B6X1Eaoa+gOdkArRi0M7BbwKHauENahE6CMrveIBNNesOhCkvScO/A i593kkGA/wbBUyW7ckhON+UPpr351NDk24ubAa51UCFmN2/HsQZXpr/a7BQELoRoT/g4 VfAw0hLKjrJSQMDoAHo3rlddCdqhVIZ/aGGOUSbCjamLuX7byDfb2Dyt8FDxrfEK1N60 JAQ2uumbdpeZL3j98Tkal2glWYgdHFHxtv7EXNvObkz97OmEh7qdjEG5pLu9jRyKVsCl dDt5QD6ZI2OpoVOqqpYUFdxQ2Tt/LMx6jKlPH4oKg90nHegtuqS4EX53456Ig8pDGzwt SpGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FJiGba+y5KGrEUxQgPj+i1n6kxwf6tPsHxl5ZtLV1Jk=; b=YIPp+6pOd20ah3MG+TT5nngsSpj7Wu40nMzb6wRShDHLS/I85F+NYsDwYi/FkE/nw5 QHkwnmX8Qg/wmHY8hRi/5W0nQn5hjuVwzy7z00H1asyAjIjj+5COmXZKtRBxlsXHHTIO URMG6txhrlc6xYt5UUYLv15JS9emPgR73Kzw/w5gybP7Zv9M31OSG40Tl4M9euQ8/I+5 DU4hdIlEh0y/7gC7WDdOny+Ypm51scwuyHhdmIYCc8ZTVfa/7c/Y7r7hfrhSmtY4J5xU /etIyEo54mAaneLZlgp08ZTwz3OQUb94jOsi1oRYMuTZn42fX2loOzRxnXFH7VFHAViz sLBw== X-Gm-Message-State: AOAM530AVb3dhaT90hHqu6vFOWLTTrFAE79i2pQXSC8pULR1Sqhe0AmM 1XfGKAvpxjTMAy4QgiC/ihyq4eNeQrzksoQ/k4A= X-Google-Smtp-Source: ABdhPJx5mT0kNIzk8te7NqOcqysk500acHoavT5wfZvcDgQRdUA4MHK7GEmuQ344scSMOsFJ5FpOveStGfHW2c/Zn8k= X-Received: by 2002:a25:6c55:: with SMTP id h82mr89848305ybc.214.1641659088758; Sat, 08 Jan 2022 08:24:48 -0800 (PST) MIME-Version: 1.0 References: <1641483250-18839-1-git-send-email-quic_pintu@quicinc.com> <1641578854-14232-1-git-send-email-quic_pintu@quicinc.com> In-Reply-To: From: Pintu Agarwal Date: Sat, 8 Jan 2022 21:54:37 +0530 Message-ID: Subject: Re: [PATCH v2] sysinfo: include availram field in sysinfo struct To: Cyrill Gorcunov 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 884AF1C000D X-Stat-Signature: wcnyobxhhcennaes851wmtob8gduqq5q Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Er0wHgv/"; spf=pass (imf21.hostedemail.com: domain of pintu.ping@gmail.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=pintu.ping@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1641659089-83982 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, 8 Jan 2022 at 02:31, Cyrill Gorcunov wrote: > > On Fri, Jan 07, 2022 at 11:37:34PM +0530, Pintu Kumar wrote: > > The sysinfo member does not have any "available ram" field and > > the bufferram field is not much helpful either, to get a rough > > estimate of available ram needed for allocation. > > > > One needs to parse MemAvailable field separately from /proc/meminfo > > to get this info instead of directly getting if from sysinfo itself. > > Who exactly needs this change? Do you have some application for which > parsing /proc/meminfo is a hot path so it needs this information via > sysinfo interface? > 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. > 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 ? > > diff --git a/kernel/sys.c b/kernel/sys.c > > index ecc4cf0..7059515 100644 > > --- a/kernel/sys.c > > +++ b/kernel/sys.c > > @@ -2671,6 +2671,7 @@ static int do_sysinfo(struct sysinfo *info) > > info->freeram <<= bitcount; > > info->sharedram <<= bitcount; > > info->bufferram <<= bitcount; > > + info->availram <<= bitcount; > > info->totalswap <<= bitcount; > > info->freeswap <<= bitcount; > > info->totalhigh <<= bitcount; > > @@ -2700,6 +2701,7 @@ struct compat_sysinfo { > > u32 freeram; > > u32 sharedram; > > u32 bufferram; > > + u32 availram; > > If only I'm not missing something ovious, this is part of UAPI as well. Yes, this structure is part of the common UAPI header.