Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1332369
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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