Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1332369

Re: [RFC PATCH 3/3] mm: increase scalability of global memory commitment accounting

From Tim Chen <tim.c.chen@linux.intel.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 3/3] mm: increase scalability of global memory commitment accounting
Date 2016-02-11 22:20 +0100
Message-ID <r16OC-5Vk-9@gated-at.bofh.it> (permalink)
References (1 earlier) <r0Epk-3tO-9@gated-at.bofh.it> <r0Hnc-5O7-21@gated-at.bofh.it> <r0KuK-7H1-23@gated-at.bofh.it> <r0NiW-16K-5@gated-at.bofh.it> <r16vg-5ys-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, 2016-02-11 at 12:51 -0800, Andrew Morton wrote:
> On Wed, 10 Feb 2016 16:24:16 -0800 Tim Chen <tim.c.chen@linux.intel.com> wrote:
> 
> > On Wed, 2016-02-10 at 13:28 -0800, Andrew Morton wrote:
> > 
> > > 
> > > If a process is unmapping 4MB then it's pretty crazy for us to be
> > > hitting the percpu_counter 32 separate times for that single operation.
> > > 
> > > Is there some way in which we can batch up the modifications within the
> > > caller and update the counter less frequently?  Perhaps even in a
> > > single hit?
> > 
> > I think the problem is the batch size is too small and we overflow
> > the local counter into the global counter for 4M allocations.
> 
> That's one way of looking at the issue.  The other way (which I point
> out above) is that we're calling vm_[un]_acct_memory too frequently
> when mapping/unmapping 4M segments.
> 
> Exactly which mmap.c callsite is causing this issue?

I suspect it is __vm_enough_memory called from do_brk or mmap_region in
Andrey's test case.

Tim

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH 3/3] mm: increase scalability of global memory commitment accounting Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-02-10 16:00 +0100
  Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Konstantin Khlebnikov <koct9i@gmail.com> - 2016-02-10 18:50 +0100
    Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-02-11 14:40 +0100
      Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Tim Chen <tim.c.chen@linux.intel.com> - 2016-02-11 18:10 +0100
  Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Tim Chen <tim.c.chen@linux.intel.com> - 2016-02-10 19:10 +0100
    Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Andrew Morton <akpm@linux-foundation.org> - 2016-02-10 22:30 +0100
      Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Tim Chen <tim.c.chen@linux.intel.com> - 2016-02-11 01:30 +0100
        Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-02-11 15:00 +0100
          Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Tim Chen <tim.c.chen@linux.intel.com> - 2016-02-11 19:30 +0100
            Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Dave Hansen <dave@sr71.net> - 2016-02-11 20:50 +0100
        Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Andrew Morton <akpm@linux-foundation.org> - 2016-02-11 22:00 +0100
          Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Tim Chen <tim.c.chen@linux.intel.com> - 2016-02-11 22:20 +0100
          Re: [RFC PATCH 3/3] mm: increase scalability of global memory  commitment accounting Andrey Ryabinin <aryabinin@virtuozzo.com> - 2016-02-12 13:30 +0100

csiph-web