Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753682AbdHQWCo (ORCPT ); Thu, 17 Aug 2017 18:02:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36526 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752632AbdHQWCn (ORCPT ); Thu, 17 Aug 2017 18:02:43 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6136381DF1 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jglisse@redhat.com Date: Thu, 17 Aug 2017 18:02:40 -0400 From: Jerome Glisse To: Dan Williams Cc: Andrew Morton , "linux-kernel@vger.kernel.org" , Linux MM , John Hubbard , David Nellans , Balbir Singh Subject: Re: [HMM-v25 00/19] HMM (Heterogeneous Memory Management) v25 Message-ID: <20170817220240.GE2872@redhat.com> References: <20170817000548.32038-1-jglisse@redhat.com> <20170817143916.63fca76e4c1fd841e0afd4cf@linux-foundation.org> <20170817215549.GD2872@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 17 Aug 2017 22:02:43 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1735 Lines: 37 On Thu, Aug 17, 2017 at 02:59:20PM -0700, Dan Williams wrote: > On Thu, Aug 17, 2017 at 2:55 PM, Jerome Glisse wrote: > > On Thu, Aug 17, 2017 at 02:39:16PM -0700, Andrew Morton wrote: > >> On Wed, 16 Aug 2017 20:05:29 -0400 J__r__me Glisse wrote: > >> > >> > Heterogeneous Memory Management (HMM) (description and justification) > >> > >> The patchset adds 55 kbytes to x86_64's mm/*.o and there doesn't appear > >> to be any way of avoiding this overhead, or of avoiding whatever > >> runtime overheads are added. > > > > HMM have already been integrated in couple of Red Hat kernel and AFAIK there > > is no runtime performance issue reported. Thought the RHEL version does not > > use static key as Dan asked. > > > >> > >> It also adds 18k to arm's mm/*.o and arm doesn't support HMM at all. > >> > >> So that's all quite a lot of bloat for systems which get no benefit from > >> the patchset. What can we do to improve this situation (a lot)? > > > > I will look into why object file grow so much on arm. My guess is that the > > new migrate code is the bulk of that. I can hide the new page migration code > > behind a kernel configuration flag. > > Shouldn't we completely disable all of it unless there is a driver in > the kernel that selects it? At one point people asked to be able to use the new migrate helper without HMM and hence why it is not behind any HMM kconfig. IIRC even ARM folks were interested pretty much all SOC have several DMA engine that site idle and i think people where toying with the idea of using this new helper to make use of them. But i can add a different kconfig to hide this code and if people want to use it they will have to select it. J?r?me