From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751043AbdCQIYb (ORCPT ); Fri, 17 Mar 2017 04:24:31 -0400 Received: from mx2.suse.de ([195.135.220.15]:46044 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750932AbdCQIY2 (ORCPT ); Fri, 17 Mar 2017 04:24:28 -0400 Date: Fri, 17 Mar 2017 08:47:08 +0100 From: Michal Hocko To: Tim Chen , Peter Zijlstra Cc: Aaron Lu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Hansen , Tim Chen , Andrew Morton , Ying Huang Subject: Re: [PATCH v2 0/5] mm: support parallel free of memory Message-ID: <20170317074707.GB26298@dhcp22.suse.cz> References: <1489568404-7817-1-git-send-email-aaron.lu@intel.com> <20170315141813.GB32626@dhcp22.suse.cz> <20170315154406.GF2442@aaronlu.sh.intel.com> <20170315162843.GA27197@dhcp22.suse.cz> <1489613914.2733.96.camel@linux.intel.com> <20170316090732.GF30501@dhcp22.suse.cz> <1489689381.2733.114.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1489689381.2733.114.camel@linux.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 16-03-17 11:36:21, Tim Chen wrote: [...] > Perhaps we can only do this expedited exit only when there are idle cpus around. > We can use the root sched domain's overload indicator for such a quick check. This is not so easy, I am afraid. Those CPUs might be idle for a good reason (power saving etc.). You will never know by simply checking one metric. This is why doing these optimistic parallelization optimizations is far from trivial. This is not the first time somebody wants to do this. People are trying to make THP migration faster doing the similar thing. I guess we really need a help from the scheduler to do this properly, though. I've been thinking about an API (e.g. try_to_run_in_backgroun) which would evaluate all these nasty details and either return with -EBUSY or kick the background thread to accomplish the work if the system is reasonably idle. I am not really sure whether such an API is viable though. Peter, what do you think? -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id D0CA26B038C for ; Fri, 17 Mar 2017 03:47:12 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id g8so2242885wmg.7 for ; Fri, 17 Mar 2017 00:47:12 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id d47si10015634wrd.322.2017.03.17.00.47.11 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 17 Mar 2017 00:47:11 -0700 (PDT) Date: Fri, 17 Mar 2017 08:47:08 +0100 From: Michal Hocko Subject: Re: [PATCH v2 0/5] mm: support parallel free of memory Message-ID: <20170317074707.GB26298@dhcp22.suse.cz> References: <1489568404-7817-1-git-send-email-aaron.lu@intel.com> <20170315141813.GB32626@dhcp22.suse.cz> <20170315154406.GF2442@aaronlu.sh.intel.com> <20170315162843.GA27197@dhcp22.suse.cz> <1489613914.2733.96.camel@linux.intel.com> <20170316090732.GF30501@dhcp22.suse.cz> <1489689381.2733.114.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1489689381.2733.114.camel@linux.intel.com> Sender: owner-linux-mm@kvack.org List-ID: To: Tim Chen , Peter Zijlstra Cc: Aaron Lu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Hansen , Tim Chen , Andrew Morton , Ying Huang On Thu 16-03-17 11:36:21, Tim Chen wrote: [...] > Perhaps we can only do this expedited exit only when there are idle cpus around. > We can use the root sched domain's overload indicator for such a quick check. This is not so easy, I am afraid. Those CPUs might be idle for a good reason (power saving etc.). You will never know by simply checking one metric. This is why doing these optimistic parallelization optimizations is far from trivial. This is not the first time somebody wants to do this. People are trying to make THP migration faster doing the similar thing. I guess we really need a help from the scheduler to do this properly, though. I've been thinking about an API (e.g. try_to_run_in_backgroun) which would evaluate all these nasty details and either return with -EBUSY or kick the background thread to accomplish the work if the system is reasonably idle. I am not really sure whether such an API is viable though. Peter, what do you think? -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org