linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Sonny Rao <sonnyrao@chromium.org>
To: Baoquan He <bhe@redhat.com>
Cc: Yu Zhao <yuzhao@google.com>,
	linux-mm@kvack.org,  David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: ABI compatibility for /proc/zoneinfo
Date: Mon, 10 Aug 2020 20:18:11 -0700	[thread overview]
Message-ID: <CAPz6YkVF-oo6xO3wmXtHv=iiTA0WQUBBbnTQJzG3vkPMbCvL2Q@mail.gmail.com> (raw)
In-Reply-To: <20200811023712.GB10792@MiWiFi-R3L-srv>

On Mon, Aug 10, 2020 at 7:37 PM Baoquan He <bhe@redhat.com> wrote:
>
> On 08/10/20 at 03:46pm, Yu Zhao wrote:
> > On Mon, Aug 10, 2020 at 02:24:03PM -0700, Sonny Rao wrote:
> > > We (Chrome OS) noticed recently one of our tests started failing on
> > > upstream kernels while parsing /proc/zoneinfo
> > > I think this patch is the cause:
> > >
> > > 26e7deadaae17 mm/vmstat.c: do not show lowmem reserve protection
> > > information of empty zone
> > >
> > > Maybe our parser was being overly strict by looking for the protection
> > > line, and it's not hard to fix but raised the question of whether there's
> > > any ABI compatibility guarantees about these files?
> >
> > According to Documentation/admin-guide/sysctl/vm.rst, "Each zone has
> > an array of protection pages". I'm not sure if this is the guarantee,
> > but the doc should reflect the actual format.
>
> The current code will list all zones in one memory node, even though
> that node only has one existing zone. E.g in below node 1,
> it only has NORMAL zone, but we will list zone DMA, DMA32, MOVABLE,
> DEVICE which are all empty zone, namely doesn't exist. So, each zone
> has an array of protection pages, it should not include the nonexistent
> zone. I thought nobody would check the protection line of an empty zone,
> seems I was wrong.


This particular parser was written as a state machine and that line
was a convenient thing to look for to mark the end of each zone.
AFAICT, there's no explicit documentation on the layout of that file
though.

>
>
> (Note that below /proc/zoneinfo is from an old system, protection line
> is still existing for empty zone)
> Node 1, zone      DMA
>   pages free     0
>         min      0
>         low      0
>         high     0
>         spanned  0
>         present  0
>         managed  0
>         protection: (0, 0, 61854, 61854, 61854)
> Node 1, zone    DMA32
>   pages free     0
>         min      0
>         low      0
>         high     0
>         spanned  0
>         present  0
>         managed  0
>         protection: (0, 0, 61854, 61854, 61854)
> Node 1, zone   Normal
>   per-node stats
>       nr_inactive_anon 259
>       nr_active_anon 11926
> ...
>       nr_written   0
>       nr_kernel_misc_reclaimable 0
>   pages free     16206452
>   pages free     16206452
>         min      11280
>         low      27114
>         high     42948
>         spanned  16777216
>         present  16777216
>         managed  15834637
>         protection: (0, 0, 0, 0, 0)
> ...
>
> Node 1, zone  Movable
>   pages free     0
>         min      0
>         low      0
>         high     0
>         spanned  0
>         present  0
>         managed  0
>         protection: (0, 0, 0, 0, 0)
> Node 1, zone   Device
>   pages free     0
>         min      0
>         low      0
>         high     0
>         spanned  0
>         present  0
>         managed  0
>         protection: (0, 0, 0, 0, 0)
> >
>


  reply	other threads:[~2020-08-11  3:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-10 21:24 Sonny Rao
2020-08-10 21:46 ` Yu Zhao
2020-08-11  2:37   ` Baoquan He
2020-08-11  3:18     ` Sonny Rao [this message]
2020-08-11  3:58       ` Baoquan He
2020-08-11  4:01       ` Andrew Morton
2020-08-11  4:07         ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPz6YkVF-oo6xO3wmXtHv=iiTA0WQUBBbnTQJzG3vkPMbCvL2Q@mail.gmail.com' \
    --to=sonnyrao@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=yuzhao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox