From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Minchan Kim <minchan@kernel.org>
Cc: Vinayak Menon <vinmenon@codeaurora.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
dan.j.williams@intel.com, mgorman@suse.de, vbabka@suse.cz,
kirill.shutemov@linux.intel.com, dave.hansen@linux.intel.com,
hughd@google.com
Subject: Re: [PATCH] mm: make fault_around_bytes configurable
Date: Tue, 17 May 2016 15:34:23 +0300 [thread overview]
Message-ID: <20160517123423.GF9540@node.shutemov.name> (raw)
In-Reply-To: <20160516145632.GA2342@blaptop>
On Mon, May 16, 2016 at 11:56:32PM +0900, Minchan Kim wrote:
> On Mon, May 16, 2016 at 05:29:00PM +0300, Kirill A. Shutemov wrote:
> > > Kirill,
> > > You wanted to test non-HW access bit system and I did.
> > > What's your opinion?
> >
> > Sorry, for late response.
> >
> > My patch is incomlete: we need to find a way to not mark pte as old if we
> > handle page fault for the address the pte represents.
>
> I'm sure you can handle it but my point is there wouldn't be a big gain
> although you can handle it in non-HW access bit system. Okay, let's be
> more clear because I don't have every non-HW access bit architecture.
> At least, current mobile workload in ARM which I have wouldn't be huge
> benefit.
> I will say one more.
> I tested the workload on quad-core system and core speed is not so slow
> compared to recent other mobile phone SoC. Even when I tested the benchmark
> without pte_mkold, the benefit is within noise because storage is really
> slow so major fault is dominant factor. So, I decide test storage from eMMC
> to eSATA. And then finally, I manage to see the a little beneift with
> fault_around without pte_mkold.
>
> However, let's consider side-effect aspect from fault_around.
>
> 1. Increase slab shrinking compard to old
> 2. high level vmpressure compared to old
>
> With considering that regressions on my system, it's really not worth to
> try at the moment.
> That's why I wanted to disable fault_around as default in non-HW access
> bit system.
Feel free to post such patch. I guess it's reasonable.
> > Once this will be done, the number of page faults shouldn't be higher with
> > fault-around enabled even on machines without hardware accessed bit. This
> > will address performance regression with the patch on such machines.
>
> Although you solves that, I guess the benefit would be marginal in
> some architectures but we should solve above side-effects.
>
> >
> > I'll try to find time to update the patch soon.
>
> I hope you can solve above those regressions as well.
The patch is posted. Please test.
--
Kirill A. Shutemov
--
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: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Minchan Kim <minchan@kernel.org>
Cc: Vinayak Menon <vinmenon@codeaurora.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
dan.j.williams@intel.com, mgorman@suse.de, vbabka@suse.cz,
kirill.shutemov@linux.intel.com, dave.hansen@linux.intel.com,
hughd@google.com
Subject: Re: [PATCH] mm: make fault_around_bytes configurable
Date: Tue, 17 May 2016 15:34:23 +0300 [thread overview]
Message-ID: <20160517123423.GF9540@node.shutemov.name> (raw)
In-Reply-To: <20160516145632.GA2342@blaptop>
On Mon, May 16, 2016 at 11:56:32PM +0900, Minchan Kim wrote:
> On Mon, May 16, 2016 at 05:29:00PM +0300, Kirill A. Shutemov wrote:
> > > Kirill,
> > > You wanted to test non-HW access bit system and I did.
> > > What's your opinion?
> >
> > Sorry, for late response.
> >
> > My patch is incomlete: we need to find a way to not mark pte as old if we
> > handle page fault for the address the pte represents.
>
> I'm sure you can handle it but my point is there wouldn't be a big gain
> although you can handle it in non-HW access bit system. Okay, let's be
> more clear because I don't have every non-HW access bit architecture.
> At least, current mobile workload in ARM which I have wouldn't be huge
> benefit.
> I will say one more.
> I tested the workload on quad-core system and core speed is not so slow
> compared to recent other mobile phone SoC. Even when I tested the benchmark
> without pte_mkold, the benefit is within noise because storage is really
> slow so major fault is dominant factor. So, I decide test storage from eMMC
> to eSATA. And then finally, I manage to see the a little beneift with
> fault_around without pte_mkold.
>
> However, let's consider side-effect aspect from fault_around.
>
> 1. Increase slab shrinking compard to old
> 2. high level vmpressure compared to old
>
> With considering that regressions on my system, it's really not worth to
> try at the moment.
> That's why I wanted to disable fault_around as default in non-HW access
> bit system.
Feel free to post such patch. I guess it's reasonable.
> > Once this will be done, the number of page faults shouldn't be higher with
> > fault-around enabled even on machines without hardware accessed bit. This
> > will address performance regression with the patch on such machines.
>
> Although you solves that, I guess the benefit would be marginal in
> some architectures but we should solve above side-effects.
>
> >
> > I'll try to find time to update the patch soon.
>
> I hope you can solve above those regressions as well.
The patch is posted. Please test.
--
Kirill A. Shutemov
next prev parent reply other threads:[~2016-05-17 12:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-18 15:17 [PATCH] mm: make fault_around_bytes configurable Vinayak Menon
2016-04-18 15:17 ` Vinayak Menon
2016-04-22 0:01 ` Andrew Morton
2016-04-22 0:01 ` Andrew Morton
2016-04-22 8:45 ` Vinayak Menon
2016-04-22 8:45 ` Vinayak Menon
2016-04-22 9:44 ` Kirill A. Shutemov
2016-04-22 9:44 ` Kirill A. Shutemov
2016-04-22 15:09 ` Minchan Kim
2016-04-22 15:09 ` Minchan Kim
2016-04-22 15:16 ` Kirill A. Shutemov
2016-04-22 15:16 ` Kirill A. Shutemov
2016-04-25 11:51 ` Vinayak Menon
2016-04-25 11:51 ` Vinayak Menon
2016-05-09 7:32 ` Minchan Kim
2016-05-09 7:32 ` Minchan Kim
2016-05-10 2:48 ` Minchan Kim
2016-05-10 2:48 ` Minchan Kim
2016-05-16 14:18 ` Minchan Kim
2016-05-16 14:18 ` Minchan Kim
2016-05-16 14:29 ` Kirill A. Shutemov
2016-05-16 14:29 ` Kirill A. Shutemov
2016-05-16 14:56 ` Minchan Kim
2016-05-16 14:56 ` Minchan Kim
2016-05-17 12:34 ` Kirill A. Shutemov [this message]
2016-05-17 12:34 ` Kirill A. Shutemov
2016-04-22 14:02 ` Minchan Kim
2016-04-22 14:02 ` Minchan Kim
2016-04-22 14:11 ` Kirill A. Shutemov
2016-04-22 14:11 ` Kirill A. Shutemov
2016-04-22 14:17 ` Kirill A. Shutemov
2016-04-22 14:17 ` Kirill A. Shutemov
2016-04-22 14:50 ` Minchan Kim
2016-04-22 14:50 ` Minchan Kim
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=20160517123423.GF9540@node.shutemov.name \
--to=kirill@shutemov.name \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=vbabka@suse.cz \
--cc=vinmenon@codeaurora.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.