From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751740AbdCACgS (ORCPT ); Tue, 28 Feb 2017 21:36:18 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:37264 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751485AbdCACfz (ORCPT ); Tue, 28 Feb 2017 21:35:55 -0500 Date: Tue, 28 Feb 2017 16:39:47 -0800 From: Andrew Morton To: Aaron Lu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Hansen , Tim Chen , Ying Huang Subject: Re: [PATCH 0/5] mm: support parallel free of memory Message-Id: <20170228163947.cbd83e48dcb149c697b316cd@linux-foundation.org> In-Reply-To: <20170224114036.15621-1-aaron.lu@intel.com> References: <20170224114036.15621-1-aaron.lu@intel.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 24 Feb 2017 19:40:31 +0800 Aaron Lu wrote: > For regular processes, the time taken in its exit() path to free its > used memory is not a problem. But there are heavy ones that consume > several Terabytes memory and the time taken to free its memory could > last more than ten minutes. > > To optimize this use case, a parallel free method is proposed here. > For detailed explanation, please refer to patch 2/5. > > I'm not sure if we need patch 4/5 which can avoid page accumulation > being interrupted in some case(patch description has more information). > My test case, which only deal with anon memory doesn't get any help out > of this of course. It can be safely dropped if it is deemed not useful. > > A test program that did a single malloc() of 320G memory is used to see > how useful the proposed parallel free solution is, the time calculated > is for the free() call. Test machine is a Haswell EX which has > 4nodes/72cores/144threads with 512G memory. All tests are done with THP > disabled. > > kernel time > v4.10 10.8s __2.8% > this patch(with default setting) 5.795s __5.8% Dumb question: why not do this in userspace, presumably as part of the malloc() library? malloc knows where all the memory is and should be able to kick off N threads to run around munmapping everything?