Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3856993imu; Mon, 28 Jan 2019 12:06:50 -0800 (PST) X-Google-Smtp-Source: ALg8bN61kcshMs/m70jXO2PEpcizL4GqeU2XbK3QEIPBMZmC35fXFdCjc/5QE7s2LCtHGJUNb0Vh X-Received: by 2002:a62:e0d8:: with SMTP id d85mr22844463pfm.214.1548706010468; Mon, 28 Jan 2019 12:06:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548706010; cv=none; d=google.com; s=arc-20160816; b=T+ltscRuuNNsJ6JMcbMorFCGRFt91kmrUt1eTa/gwgBRdLMu5EL42ZZY77WxcNCop/ bhS/OfNMy7gGBrcmuW3SJ9MNTkqWyAAq2ouEM6oRy+vvxx/piPmmM5qQyH/eq+59Afuy LmY495D7+RyT+3a51k+7qGImj/9WsefKS2IhF0wFLGlydh09A7lgOzmpCSRmNBXSFpNz h/pCU44ThNKksWxJ17Ex6AxC5AJjYwwBxHKF445UrJEQBfsscj+BEDYhGGrgqT8GGKNF 9BB8Zm9XRkJfswjJfbZ41CGxEPH1E5+55IEKcYjsjNsxuGsREdxnElXOgQ8arP/ZNfCv /eww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Q07e/peENslT9pMfwiarlrwhYdvlmbA/0uPKfqvBYjo=; b=dIzELbreWsECguR7B/GmghyqrrmomBYkjCFlNP3SBKyG1suSyYpWf8CYG32+gdRR2F eViXSGuCu2tjOlGeLUQfXCiBwJsSKs/sZ2BwFRquvIUc34NvmG4TyYsHPD/KI0v9VWxF qL0e5Gjhk4bNcvpzHHWlB7yLGX/rLlTQSbvhMDpHKlBYgsQBS189AYlIqhiI4aSEZ/9C xO7lWN4jkv2E7JPp07bkP8Py+Eq3+Zxc6pB3+t76hGoEDqxNMsrAJWOQE0KbHLWywhfU Ut2xfUUvbg65K37tzcPRlGsZeTSJETIZmjIqjl94Tpvqf5IsK3E+idJGddTpVxlzo/L6 jzQw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o7si33498636pgl.42.2019.01.28.12.06.34; Mon, 28 Jan 2019 12:06:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727973AbfA1UEc (ORCPT + 99 others); Mon, 28 Jan 2019 15:04:32 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:46970 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726661AbfA1UEc (ORCPT ); Mon, 28 Jan 2019 15:04:32 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id BC7C92477; Mon, 28 Jan 2019 20:04:30 +0000 (UTC) Date: Mon, 28 Jan 2019 12:04:29 -0800 From: Andrew Morton To: "Uladzislau Rezki (Sony)" Cc: Michal Hocko , Matthew Wilcox , linux-mm@kvack.org, LKML , Thomas Garnier , Oleksiy Avramchenko , Steven Rostedt , Joel Fernandes , Thomas Gleixner , Ingo Molnar , Tejun Heo Subject: Re: [PATCH v1 2/2] mm: add priority threshold to __purge_vmap_area_lazy() Message-Id: <20190128120429.17819bd348753c2d7ed3a7b9@linux-foundation.org> In-Reply-To: <20190124115648.9433-3-urezki@gmail.com> References: <20190124115648.9433-1-urezki@gmail.com> <20190124115648.9433-3-urezki@gmail.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 24 Jan 2019 12:56:48 +0100 "Uladzislau Rezki (Sony)" wrote: > commit 763b218ddfaf ("mm: add preempt points into > __purge_vmap_area_lazy()") > > introduced some preempt points, one of those is making an > allocation more prioritized over lazy free of vmap areas. > > Prioritizing an allocation over freeing does not work well > all the time, i.e. it should be rather a compromise. > > 1) Number of lazy pages directly influence on busy list length > thus on operations like: allocation, lookup, unmap, remove, etc. > > 2) Under heavy stress of vmalloc subsystem i run into a situation > when memory usage gets increased hitting out_of_memory -> panic > state due to completely blocking of logic that frees vmap areas > in the __purge_vmap_area_lazy() function. > > Establish a threshold passing which the freeing is prioritized > back over allocation creating a balance between each other. It would be useful to credit the vmalloc test driver for this discovery, and perhaps to identify specifically which test triggered the kernel misbehaviour. Please send along suitable words and I'll add them. > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -661,23 +661,27 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) > struct llist_node *valist; > struct vmap_area *va; > struct vmap_area *n_va; > - bool do_free = false; > + int resched_threshold; > > lockdep_assert_held(&vmap_purge_lock); > > valist = llist_del_all(&vmap_purge_list); > + if (unlikely(valist == NULL)) > + return false; Why this change? > + /* > + * TODO: to calculate a flush range without looping. > + * The list can be up to lazy_max_pages() elements. > + */ How important is this? > llist_for_each_entry(va, valist, purge_list) { > if (va->va_start < start) > start = va->va_start; > if (va->va_end > end) > end = va->va_end; > - do_free = true; > } > > - if (!do_free) > - return false; > - > flush_tlb_kernel_range(start, end); > + resched_threshold = (int) lazy_max_pages() << 1; Is the typecast really needed? Perhaps resched_threshold shiould have unsigned long type and perhaps vmap_lazy_nr should be atomic_long_t? > spin_lock(&vmap_area_lock); > llist_for_each_entry_safe(va, n_va, valist, purge_list) { > @@ -685,7 +689,9 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) > > __free_vmap_area(va); > atomic_sub(nr, &vmap_lazy_nr); > - cond_resched_lock(&vmap_area_lock); > + > + if (atomic_read(&vmap_lazy_nr) < resched_threshold) > + cond_resched_lock(&vmap_area_lock); > } > spin_unlock(&vmap_area_lock); > return true;