Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: dancol@xxxxxxxxxx
- Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions
- From: Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>
- Date: Sat, 13 Oct 2018 10:50:39 -0700
- Cc: David Miller <davem@xxxxxxxxxxxxx>, kirill@xxxxxxxxxxxxx, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>, kernel-team@xxxxxxxxxxx, Minchan Kim <minchan@xxxxxxxxxx>, Ramon Pantin <pantin@xxxxxxxxxx>, Hugh Dickins <hughd@xxxxxxxxxx>, Lokesh Gidra <lokeshgidra@xxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, aryabinin@xxxxxxxxxxxxx, luto@xxxxxxxxxx, bp@xxxxxxxxx, catalin.marinas@xxxxxxx, Chris Zankel <chris@xxxxxxxxxx>, dave.hansen@xxxxxxxxxxxxxxx, elfring@xxxxxxxxxxxxxxxxxxxxx, fenghua.yu@xxxxxxxxx, geert@xxxxxxxxxxxxxx, gxt@xxxxxxxxxx, deller@xxxxxx, mingo@xxxxxxxxxx, jejb@xxxxxxxxxxxxxxxx, jdike@xxxxxxxxxxx, Jonas Bonn <jonas@xxxxxxxxxxxx>, Julia Lawall <Julia.Lawall@xxxxxxx>, kasan-dev@xxxxxxxxxxxxxxxx, kvmarm@xxxxxxxxxxxxxxxxxxxxx, lftan@xxxxxxxxxx, linux-alpha@xxxxxxxxxxxxxxx, linux-hexagon@xxxxxxxxxxxxxxx, linux-ia64@xxxxxxxxxxxxxxx, linux-m68k@xxxxxxxxxxxxxxx, linux-mips@xxxxxxxxxxxxxx, linux-mm <linux-mm@xxxxxxxxx>, linux-parisc@xxxxxxxxxxxxxxx, linuxppc-dev@xxxxxxxxxxxxxxxx, linux-riscv@xxxxxxxxxxxxxxxxxxx, linux-s390@xxxxxxxxxxxxxxx, linux-sh@xxxxxxxxxxxxxxx, linux-snps-arc@xxxxxxxxxxxxxxxxxxx, linux-um@xxxxxxxxxxxxxxxxxxx, linux-xtensa@xxxxxxxxxxxxxxxx, Max Filippov <jcmvbkbc@xxxxxxxxx>, nios2-dev@xxxxxxxxxxxxxxxxxxxxxx, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, richard@xxxxxx
- In-reply-to: <CAKOZueu2wdkeUFYLQ8qE48yJs1_uRz-9RVJRkp==CL=jp=Q8+g@mail.gmail.com>
- References: <20181012013756.11285-2-joel@joelfernandes.org> <20181012113056.gxhcbrqyu7k7xnyv@kshutemo-mobl1> <20181012125046.GA170912@joelaf.mtv.corp.google.com> <20181012.111836.1569129998592378186.davem@davemloft.net> <20181013013540.GA207108@joelaf.mtv.corp.google.com> <CAKOZueuNvWvn18vffJWpbpg7h-uScT8gXrrudTB2pnT4M2HJ_w@mail.gmail.com> <20181013014429.GB207108@joelaf.mtv.corp.google.com> <CAKOZues25aaKz3_AiyfJ=r2QBd5MghgY3ky_ptg4Z8=ST4DCgw@mail.gmail.com> <20181013021057.GA213522@joelaf.mtv.corp.google.com> <CAKOZueu2wdkeUFYLQ8qE48yJs1_uRz-9RVJRkp==CL=jp=Q8+g@mail.gmail.com>
- User-agent: Mutt/1.10.1 (2018-07-13)
On Fri, Oct 12, 2018 at 07:25:08PM -0700, Daniel Colascione wrote:
[...]
> > But anyway, I think this runtime detection thing is not needed. THP is
> > actually expected to be as fast as this anyway, so if that's available then
> > we should already be as fast.
>
> Ah, I think the commit message is confusing. (Or else I'm misreading
> the patch now.) It's not quite that we're disabling the feature when
> THP is enabled anywhere, but rather that we use the move_huge_pmd path
> for huge PMDs and use the new code only for non-huge PMDs. (Right?) If
> that's the case, the commit message shouldn't say "Incase THP is
> enabled, the optimization is skipped". Even if THP is enabled on a
> system generally, we might use the new PMD-moving code for mapping
> types that don't support THP-ization, right?
That is true. Ok, I guess I can update the commit message to be more accurate
about that.
> > This is for non-THP where THP cannot be enabled
> > and there is still room for some improvement. Most/all architectures will be
> > just fine with this. This flag is more of a safety-net type of thing where in
> > the future if there is this one or two weird architectures that don't play
> > well, then they can turn it off at the architecture level by not selecting
> > the flag. See my latest patches for the per-architecture compile-time
> > controls. Ideally we'd like to blanket turn it on on all, but this is just
> > playing it extra safe as Kirill and me were discussing on other threads.
>
> Sure. I'm just pointing out that the 500x performance different turns
> the operation into a qualitatively different feature, so if we expect
> to actually ship a mainstream architecture without support for this
> thing, we should make it explicit. If we're not, we shouldn't.
We can make it explicit by enabling it in such a mainstream architecture is
my point. Also if the optimization is not doing what its supposed to, then
userspace will also just know by measuring the time.
thanks,
- Joel
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]