All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rafael Aquini <aquini@redhat.com>
To: Motohiro Kosaki <Motohiro.Kosaki@us.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Motohiro Kosaki JP <kosaki.motohiro@jp.fujitsu.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: export NR_SHMEM via sysinfo(2) / si_meminfo() interfaces
Date: Wed, 25 Jun 2014 16:16:04 -0400	[thread overview]
Message-ID: <20140625201603.GA1534@t510.redhat.com> (raw)
In-Reply-To: <6B2BA408B38BA1478B473C31C3D2074E341D585464@SV-EXCHANGE1.Corp.FC.LOCAL>

On Wed, Jun 25, 2014 at 12:41:17PM -0700, Motohiro Kosaki wrote:
> 
> 
> > -----Original Message-----
> > From: Rafael Aquini [mailto:aquini@redhat.com]
> > Sent: Wednesday, June 25, 2014 2:40 PM
> > To: linux-mm@kvack.org
> > Cc: Andrew Morton; Rik van Riel; Mel Gorman; Johannes Weiner; Motohiro Kosaki JP; linux-kernel@vger.kernel.org
> > Subject: [PATCH] mm: export NR_SHMEM via sysinfo(2) / si_meminfo() interfaces
> > 
> > This patch leverages the addition of explicit accounting for pages used by shmem/tmpfs -- "4b02108 mm: oom analysis: add shmem
> > vmstat" -- in order to make the users of sysinfo(2) and si_meminfo*() friends aware of that vmstat entry consistently across the
> > interfaces.
> 
> Why?

Because we do not report consistently across the interfaces we declare
exporting that data. Check sysinfo(2) manpage, for instance:
[...]
           struct sysinfo {
               long uptime;             /* Seconds since boot */
               unsigned long loads[3];  /* 1, 5, and 15 minute load averages */
               unsigned long totalram;  /* Total usable main memory size */
               unsigned long freeram;   /* Available memory size */
               unsigned long sharedram; /* Amount of shared memory */ <<<<<
[...]

userspace tools resorting to sysinfo() syscall will get a hardcoded 0
for shared memory which is reported differently from /proc/meminfo.

Also, si_meminfo() & si_meminfo_node() are utilized within the kernel to
gather statistics for /proc/meminfo & friends, and so we can leverage collecting
sharedmem from those calls as well, just as we do for totalram, freeram & bufferram.

Regards,
-- Rafael

> Traditionally sysinfo.sharedram was not used for shmem. It was totally strange semantics and completely outdated feature. 
> So, we may reuse it for another purpose. But I'm not sure its benefit. 
> 
> Why don't you use /proc/meminfo?
> I'm afraid userland programs get a confusion. 
> 
> 
> > 
> > Signed-off-by: Rafael Aquini <aquini@redhat.com>
> > ---
> >  drivers/base/node.c | 2 +-
> >  fs/proc/meminfo.c   | 2 +-
> >  mm/page_alloc.c     | 3 ++-
> >  3 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/base/node.c b/drivers/base/node.c index 8f7ed99..c6d3ae0 100644
> > --- a/drivers/base/node.c
> > +++ b/drivers/base/node.c
> > @@ -126,7 +126,7 @@ static ssize_t node_read_meminfo(struct device *dev,
> >  		       nid, K(node_page_state(nid, NR_FILE_PAGES)),
> >  		       nid, K(node_page_state(nid, NR_FILE_MAPPED)),
> >  		       nid, K(node_page_state(nid, NR_ANON_PAGES)),
> > -		       nid, K(node_page_state(nid, NR_SHMEM)),
> > +		       nid, K(i.sharedram),
> >  		       nid, node_page_state(nid, NR_KERNEL_STACK) *
> >  				THREAD_SIZE / 1024,
> >  		       nid, K(node_page_state(nid, NR_PAGETABLE)), diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c index
> > 7445af0..aa1eee0 100644
> > --- a/fs/proc/meminfo.c
> > +++ b/fs/proc/meminfo.c
> > @@ -168,7 +168,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
> >  		K(global_page_state(NR_WRITEBACK)),
> >  		K(global_page_state(NR_ANON_PAGES)),
> >  		K(global_page_state(NR_FILE_MAPPED)),
> > -		K(global_page_state(NR_SHMEM)),
> > +		K(i.sharedram),
> >  		K(global_page_state(NR_SLAB_RECLAIMABLE) +
> >  				global_page_state(NR_SLAB_UNRECLAIMABLE)),
> >  		K(global_page_state(NR_SLAB_RECLAIMABLE)),
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 20d17f8..f72ea38 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -3040,7 +3040,7 @@ static inline void show_node(struct zone *zone)  void si_meminfo(struct sysinfo *val)  {
> >  	val->totalram = totalram_pages;
> > -	val->sharedram = 0;
> > +	val->sharedram = global_page_state(NR_SHMEM);
> >  	val->freeram = global_page_state(NR_FREE_PAGES);
> >  	val->bufferram = nr_blockdev_pages();
> >  	val->totalhigh = totalhigh_pages;
> > @@ -3060,6 +3060,7 @@ void si_meminfo_node(struct sysinfo *val, int nid)
> >  	for (zone_type = 0; zone_type < MAX_NR_ZONES; zone_type++)
> >  		managed_pages += pgdat->node_zones[zone_type].managed_pages;
> >  	val->totalram = managed_pages;
> > +	val->sharedram = node_page_state(nid, NR_SHMEM);
> >  	val->freeram = node_page_state(nid, NR_FREE_PAGES);  #ifdef CONFIG_HIGHMEM
> >  	val->totalhigh = pgdat->node_zones[ZONE_HIGHMEM].managed_pages;
> > --
> > 1.9.3
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Rafael Aquini <aquini@redhat.com>
To: Motohiro Kosaki <Motohiro.Kosaki@us.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Motohiro Kosaki JP <kosaki.motohiro@jp.fujitsu.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: export NR_SHMEM via sysinfo(2) / si_meminfo() interfaces
Date: Wed, 25 Jun 2014 16:16:04 -0400	[thread overview]
Message-ID: <20140625201603.GA1534@t510.redhat.com> (raw)
In-Reply-To: <6B2BA408B38BA1478B473C31C3D2074E341D585464@SV-EXCHANGE1.Corp.FC.LOCAL>

On Wed, Jun 25, 2014 at 12:41:17PM -0700, Motohiro Kosaki wrote:
> 
> 
> > -----Original Message-----
> > From: Rafael Aquini [mailto:aquini@redhat.com]
> > Sent: Wednesday, June 25, 2014 2:40 PM
> > To: linux-mm@kvack.org
> > Cc: Andrew Morton; Rik van Riel; Mel Gorman; Johannes Weiner; Motohiro Kosaki JP; linux-kernel@vger.kernel.org
> > Subject: [PATCH] mm: export NR_SHMEM via sysinfo(2) / si_meminfo() interfaces
> > 
> > This patch leverages the addition of explicit accounting for pages used by shmem/tmpfs -- "4b02108 mm: oom analysis: add shmem
> > vmstat" -- in order to make the users of sysinfo(2) and si_meminfo*() friends aware of that vmstat entry consistently across the
> > interfaces.
> 
> Why?

Because we do not report consistently across the interfaces we declare
exporting that data. Check sysinfo(2) manpage, for instance:
[...]
           struct sysinfo {
               long uptime;             /* Seconds since boot */
               unsigned long loads[3];  /* 1, 5, and 15 minute load averages */
               unsigned long totalram;  /* Total usable main memory size */
               unsigned long freeram;   /* Available memory size */
               unsigned long sharedram; /* Amount of shared memory */ <<<<<
[...]

userspace tools resorting to sysinfo() syscall will get a hardcoded 0
for shared memory which is reported differently from /proc/meminfo.

Also, si_meminfo() & si_meminfo_node() are utilized within the kernel to
gather statistics for /proc/meminfo & friends, and so we can leverage collecting
sharedmem from those calls as well, just as we do for totalram, freeram & bufferram.

Regards,
-- Rafael

> Traditionally sysinfo.sharedram was not used for shmem. It was totally strange semantics and completely outdated feature. 
> So, we may reuse it for another purpose. But I'm not sure its benefit. 
> 
> Why don't you use /proc/meminfo?
> I'm afraid userland programs get a confusion. 
> 
> 
> > 
> > Signed-off-by: Rafael Aquini <aquini@redhat.com>
> > ---
> >  drivers/base/node.c | 2 +-
> >  fs/proc/meminfo.c   | 2 +-
> >  mm/page_alloc.c     | 3 ++-
> >  3 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/base/node.c b/drivers/base/node.c index 8f7ed99..c6d3ae0 100644
> > --- a/drivers/base/node.c
> > +++ b/drivers/base/node.c
> > @@ -126,7 +126,7 @@ static ssize_t node_read_meminfo(struct device *dev,
> >  		       nid, K(node_page_state(nid, NR_FILE_PAGES)),
> >  		       nid, K(node_page_state(nid, NR_FILE_MAPPED)),
> >  		       nid, K(node_page_state(nid, NR_ANON_PAGES)),
> > -		       nid, K(node_page_state(nid, NR_SHMEM)),
> > +		       nid, K(i.sharedram),
> >  		       nid, node_page_state(nid, NR_KERNEL_STACK) *
> >  				THREAD_SIZE / 1024,
> >  		       nid, K(node_page_state(nid, NR_PAGETABLE)), diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c index
> > 7445af0..aa1eee0 100644
> > --- a/fs/proc/meminfo.c
> > +++ b/fs/proc/meminfo.c
> > @@ -168,7 +168,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
> >  		K(global_page_state(NR_WRITEBACK)),
> >  		K(global_page_state(NR_ANON_PAGES)),
> >  		K(global_page_state(NR_FILE_MAPPED)),
> > -		K(global_page_state(NR_SHMEM)),
> > +		K(i.sharedram),
> >  		K(global_page_state(NR_SLAB_RECLAIMABLE) +
> >  				global_page_state(NR_SLAB_UNRECLAIMABLE)),
> >  		K(global_page_state(NR_SLAB_RECLAIMABLE)),
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 20d17f8..f72ea38 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -3040,7 +3040,7 @@ static inline void show_node(struct zone *zone)  void si_meminfo(struct sysinfo *val)  {
> >  	val->totalram = totalram_pages;
> > -	val->sharedram = 0;
> > +	val->sharedram = global_page_state(NR_SHMEM);
> >  	val->freeram = global_page_state(NR_FREE_PAGES);
> >  	val->bufferram = nr_blockdev_pages();
> >  	val->totalhigh = totalhigh_pages;
> > @@ -3060,6 +3060,7 @@ void si_meminfo_node(struct sysinfo *val, int nid)
> >  	for (zone_type = 0; zone_type < MAX_NR_ZONES; zone_type++)
> >  		managed_pages += pgdat->node_zones[zone_type].managed_pages;
> >  	val->totalram = managed_pages;
> > +	val->sharedram = node_page_state(nid, NR_SHMEM);
> >  	val->freeram = node_page_state(nid, NR_FREE_PAGES);  #ifdef CONFIG_HIGHMEM
> >  	val->totalhigh = pgdat->node_zones[ZONE_HIGHMEM].managed_pages;
> > --
> > 1.9.3
> 

  reply	other threads:[~2014-06-25 20:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25 18:39 [PATCH] mm: export NR_SHMEM via sysinfo(2) / si_meminfo() interfaces Rafael Aquini
2014-06-25 18:39 ` Rafael Aquini
2014-06-25 19:41 ` Motohiro Kosaki
2014-06-25 19:41   ` Motohiro Kosaki
2014-06-25 20:16   ` Rafael Aquini [this message]
2014-06-25 20:16     ` Rafael Aquini
2014-06-25 20:27     ` Motohiro Kosaki
2014-06-25 20:27       ` Motohiro Kosaki
2014-06-25 22:54       ` Rafael Aquini
2014-06-25 22:54         ` Rafael Aquini
2014-06-26  0:12         ` KOSAKI Motohiro
2014-06-26  0:12           ` KOSAKI Motohiro
2014-06-25 20:25   ` Motohiro Kosaki
2014-06-25 20:25     ` Motohiro Kosaki

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=20140625201603.GA1534@t510.redhat.com \
    --to=aquini@redhat.com \
    --cc=Motohiro.Kosaki@us.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=riel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.