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


Groups > linux.kernel > #1331960

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

From Andrey Ryabinin <aryabinin@virtuozzo.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 3/3] mm: increase scalability of global memory commitment accounting
Date 2016-02-11 15:00 +0100
Message-ID <r0ZWP-17m-17@gated-at.bofh.it> (permalink)
References <r0Epk-3tO-11@gated-at.bofh.it> <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>
Organization linux.* mail to news gateway

Show all headers | View raw



On 02/11/2016 03:24 AM, Tim Chen 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.
> The reason for the small batch size was because we use
> percpu_counter_read_positive in __vm_enough_memory and it is not precise
> and the error could grow with large batch size.
> 
> Let's switch to the precise __percpu_counter_compare that is 
> unaffected by batch size.  It will do precise comparison and only add up
> the local per cpu counters when the global count is not precise
> enough.  
> 

I'm not certain about this. for_each_online_cpu() under spinlock somewhat doubtful.
And if we are close to limit we will be hitting slowpath all the time.


> So maybe something like the following patch with a relaxed batch size.
> I have not tested this patch much other than compiling and booting
> the kernel.  I wonder if this works for Andrey. We could relax the batch
> size further, but that will mean that we will incur the overhead
> of summing the per cpu counters earlier when the global count get close
> to the allowed limit.
> 
> Thanks.
> 
> 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