[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YdiqLKS5Sv9eWwu2@grain>
Date: Sat, 8 Jan 2022 00:01:32 +0300
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Pintu Kumar <quic_pintu@...cinc.com>
Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
linux-mm@...ck.org, ebiederm@...ssion.com,
christian.brauner@...ntu.com, sfr@...b.auug.org.au,
legion@...nel.org, sashal@...nel.org, chris.hyser@...cle.com,
ccross@...gle.com, pcc@...gle.com, dave@...olabs.net,
caoxiaofeng@...ong.com, david@...hat.com, pintu.ping@...il.com,
vbabka@...e.cz, linux-api@...r.kernel.org
Subject: Re: [PATCH v2] sysinfo: include availram field in sysinfo struct
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?
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.
> 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.
Powered by blists - more mailing lists