lkml.org 
[lkml]   [2019]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] mm: Expose lazy vfree pages to control via sysctl
From
Date
Matthew, this issue was last reported in September 2018 on K4.9.
I verified that the optimization patches mentioned by you were not
present in our downstream kernel when we faced the issue. I will check
whether issue still persist on new kernel with all these patches and
come back.

On 04/01/19 11:33 PM, Matthew Wilcox wrote:
> On Fri, Jan 04, 2019 at 09:05:41PM +0530, Ashish Mhetre wrote:
>> From: Hiroshi Doyu <hdoyu@nvidia.com>
>>
>> The purpose of lazy_max_pages is to gather virtual address space till it
>> reaches the lazy_max_pages limit and then purge with a TLB flush and hence
>> reduce the number of global TLB flushes.
>> The default value of lazy_max_pages with one CPU is 32MB and with 4 CPUs it
>> is 96MB i.e. for 4 cores, 96MB of vmalloc space will be gathered before it
>> is purged with a TLB flush.
>> This feature has shown random latency issues. For example, we have seen
>> that the kernel thread for some camera application spent 30ms in
>> __purge_vmap_area_lazy() with 4 CPUs.
>
> You're not the first to report something like this. Looking through the
> kernel logs, I see:
>
> commit 763b218ddfaf56761c19923beb7e16656f66ec62
> Author: Joel Fernandes <joelaf@google.com>
> Date: Mon Dec 12 16:44:26 2016 -0800
>
> mm: add preempt points into __purge_vmap_area_lazy()
>
> commit f9e09977671b618aeb25ddc0d4c9a84d5b5cde9d
> Author: Christoph Hellwig <hch@lst.de>
> Date: Mon Dec 12 16:44:23 2016 -0800
>
> mm: turn vmap_purge_lock into a mutex
>
> commit 80c4bd7a5e4368b680e0aeb57050a1b06eb573d8
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date: Fri May 20 16:57:38 2016 -0700
>
> mm/vmalloc: keep a separate lazy-free list
>
> So the first thing I want to do is to confirm that you see this problem
> on a modern kernel. We've had trouble with NVidia before reporting
> historical problems as if they were new.
>

\
 
 \ /
  Last update: 2019-01-06 09:42    [W:0.070 / U:1.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site