All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: calculate the various pages number to show
Date: Thu, 3 Dec 2015 18:22:27 +0000	[thread overview]
Message-ID: <20151203182227.GC3527@leverpostej> (raw)
In-Reply-To: <5657B750.6080908@huawei.com>

On Fri, Nov 27, 2015 at 09:52:16AM +0800, Xishi Qiu wrote:
> On 2015/11/26 23:49, Mark Rutland wrote:
> 
> > On Thu, Nov 26, 2015 at 11:05:32PM +0800, zhong jiang wrote:
> >> On 2015/11/25 23:04, Mark Rutland wrote:
> >>> On Wed, Nov 25, 2015 at 09:41:12PM +0800, zhongjiang wrote:
> >>>> This patch add the interface to show the number of 4KB or 64KB page,
> >>>> aims to statistics the number of different types of pages.
> >>>
> >>> What is this useful for? Why do we want it?
> >>>
> >>> What does it account for, just the swapper?
> >>>
> >>
> >> The patch is wirtten when I was in backport set_memory_ro. It can be used to
> >> detect whether there is a large page spliting and merging. large page will
> >> significantly reduce the TLB miss, and improve the system performance.
> > 
> > Ok, but typically the user isn't going to be able to do much with this
> > information. It feels more like something that should be in the page
> > table dump code (where we can calculate the values as we walk the
> > tables).
> > 
> > What is it intended to account for?
> > 
> > The entire swapper?
> > 
> > Just the linear mapping?
> 
> Hi Mark,
> 
> x86 has this information when cat /proc/meminfo, so how about just
> like x86 to show it?

The fact that another architecture has some implementation doesn't
necessarily mean it's a good idea. In this case there are concerns that
don't apply to x86, in that we support a number of page sizes, and
anything reading this needs to handle that fact.

If there's a sensible use-case, then I am not opposed to this. I don't
see the point in adding it just because we can.

A prerequisite for adding it is knowing precisely what it is intended to
describe. Otherwise it's impossible to review.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Xishi Qiu <qiuxishi@huawei.com>
Cc: zhong jiang <zhongjiang@huawei.com>,
	catalin.marinas@arm.com, will.deacon@arm.com,
	lauraa@codeaurora.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, guohanjun@huawei.com
Subject: Re: [PATCH] arm64: calculate the various pages number to show
Date: Thu, 3 Dec 2015 18:22:27 +0000	[thread overview]
Message-ID: <20151203182227.GC3527@leverpostej> (raw)
In-Reply-To: <5657B750.6080908@huawei.com>

On Fri, Nov 27, 2015 at 09:52:16AM +0800, Xishi Qiu wrote:
> On 2015/11/26 23:49, Mark Rutland wrote:
> 
> > On Thu, Nov 26, 2015 at 11:05:32PM +0800, zhong jiang wrote:
> >> On 2015/11/25 23:04, Mark Rutland wrote:
> >>> On Wed, Nov 25, 2015 at 09:41:12PM +0800, zhongjiang wrote:
> >>>> This patch add the interface to show the number of 4KB or 64KB page,
> >>>> aims to statistics the number of different types of pages.
> >>>
> >>> What is this useful for? Why do we want it?
> >>>
> >>> What does it account for, just the swapper?
> >>>
> >>
> >> The patch is wirtten when I was in backport set_memory_ro. It can be used to
> >> detect whether there is a large page spliting and merging. large page will
> >> significantly reduce the TLB miss, and improve the system performance.
> > 
> > Ok, but typically the user isn't going to be able to do much with this
> > information. It feels more like something that should be in the page
> > table dump code (where we can calculate the values as we walk the
> > tables).
> > 
> > What is it intended to account for?
> > 
> > The entire swapper?
> > 
> > Just the linear mapping?
> 
> Hi Mark,
> 
> x86 has this information when cat /proc/meminfo, so how about just
> like x86 to show it?

The fact that another architecture has some implementation doesn't
necessarily mean it's a good idea. In this case there are concerns that
don't apply to x86, in that we support a number of page sizes, and
anything reading this needs to handle that fact.

If there's a sensible use-case, then I am not opposed to this. I don't
see the point in adding it just because we can.

A prerequisite for adding it is knowing precisely what it is intended to
describe. Otherwise it's impossible to review.

Thanks,
Mark.

  reply	other threads:[~2015-12-03 18:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-25 13:41 [PATCH] arm64: calculate the various pages number to show zhongjiang
2015-11-25 13:41 ` zhongjiang
2015-11-25 15:04 ` Mark Rutland
2015-11-25 15:04   ` Mark Rutland
2015-11-26 15:05   ` zhong jiang
2015-11-26 15:05     ` zhong jiang
2015-11-26 15:49     ` Mark Rutland
2015-11-26 15:49       ` Mark Rutland
2015-11-27  1:52       ` Xishi Qiu
2015-11-27  1:52         ` Xishi Qiu
2015-12-03 18:22         ` Mark Rutland [this message]
2015-12-03 18:22           ` Mark Rutland
2015-11-27  8:40       ` zhong jiang
2015-11-27  8:40         ` zhong jiang

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=20151203182227.GC3527@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.