Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp3091178imd; Mon, 29 Oct 2018 01:17:47 -0700 (PDT) X-Google-Smtp-Source: AJdET5fFHCVNZoIyJUEjp0gFEHAAtlGRF7E3lApBol5EzubGaSi1lx/KnXxbHH7Vq/wgo/HR7218 X-Received: by 2002:a63:d513:: with SMTP id c19mr12857184pgg.287.1540801067459; Mon, 29 Oct 2018 01:17:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540801067; cv=none; d=google.com; s=arc-20160816; b=0fMCjgzpNnwaZuA1c/Wk+YcvUYRDUt15Tp4C7V13yyDWJJKWiBmOIJjPQL3FrhLGVg /HzLPOnJaqnfTptyQe77w2/b8vstX/TQ/pN7syGa8AgLIqVOuDZ2bqX4HFY2Fk3kcD2E 67oGGunQ/8qjdhmGunq9aRW0yPz28dxiLwxWmPALK1n8hYFeYrNlBx/HK7nJptOk7uqe eSBrp6syg1llVrF4w2YRd7U8d9V244PWPbTkwI+fF5IBV1P3V3dkWfyOT5FH71/smwBU vxBXSj1tzsR/jcUL9IImuhB7jLuyIDwfVAy1j5LNcSaa7pOFpksV3dckR+1IQrsDil3U VICg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=s1nQV2vAJowo7M9j7BwLObpnYo8hT6OWQCyMD2ZrNFY=; b=Lg1hYEHdWDNBTkrSyicNtupdqRA1n8TQ56F1fmCvMP+j44xJRygiE2X2symZz3FbaL PpBA+c9+w14x9T4WJXfxSs2V235FCjewVt781L+M02WC9OILWDmrubTCleTTrBHbN8Rd 9RpkcepOjERuOAfAkBE13dIHDifeVJLUy8bENTGQhNjDNpY3aBrHTDa2svEhZThNCar0 oiuhnDkJxOEGGnBDsCKYWLmtR1gsdouf+BwXpMUYoxdKFJOSw0xCh2vfSBhorDNUjruq t/UEXWYDEV+wXK9TUo1d6AB8xrFsMg0uYUJ74sV8jSRKhIGkZizNHawR801teOKEqcso 00PQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q2-v6si19266135pgs.439.2018.10.29.01.17.30; Mon, 29 Oct 2018 01:17:47 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729346AbeJ2REm (ORCPT + 99 others); Mon, 29 Oct 2018 13:04:42 -0400 Received: from mx2.suse.de ([195.135.220.15]:44024 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725969AbeJ2REm (ORCPT ); Mon, 29 Oct 2018 13:04:42 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 62187AD73; Mon, 29 Oct 2018 08:17:07 +0000 (UTC) Date: Mon, 29 Oct 2018 09:17:06 +0100 From: Michal Hocko To: miles.chen@mediatek.com Cc: Andrew Morton , Joe Perches , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, wsd_upstream@mediatek.com Subject: Re: [PATCH v3] mm/page_owner: use kvmalloc instead of kmalloc Message-ID: <20181029081706.GC32673@dhcp22.suse.cz> References: <1540790176-32339-1-git-send-email-miles.chen@mediatek.com> <20181029080708.GA32673@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181029080708.GA32673@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 29-10-18 09:07:08, Michal Hocko wrote: [...] > Besides that, the following doesn't make much sense to me. It simply > makes no sense to use vmalloc for sub page allocation regardless of > HIGHMEM. OK, it is still early morning here. Now I get the point of the patch. You just want to (ab)use highmeme for smaller requests. I do not like this, to be honest. It causes an internal fragmentation and more importantly the VMALLOC space on 32b where HIGHMEM is enabled (do we have any 64b with HIGHMEM btw?) is quite small to be wasted like that. In any case such a changes should come with some numbers and as a separate patch for sure. > > diff --git a/mm/util.c b/mm/util.c > > index 8bf08b5b5760..7b1c59b9bfbf 100644 > > --- a/mm/util.c > > +++ b/mm/util.c > > @@ -416,10 +416,10 @@ void *kvmalloc_node(size_t size, gfp_t flags, int node) > > ret = kmalloc_node(size, kmalloc_flags, node); > > > > /* > > - * It doesn't really make sense to fallback to vmalloc for sub page > > - * requests > > + * It only makes sense to fallback to vmalloc for sub page > > + * requests if we might be able to allocate highmem pages. > > */ > > - if (ret || size <= PAGE_SIZE) > > + if (ret || (!IS_ENABLED(CONFIG_HIGHMEM) && size <= PAGE_SIZE)) > > return ret; > > > > return __vmalloc_node_flags_caller(size, node, flags, > > -- > > 2.18.0 > > > > -- > Michal Hocko > SUSE Labs -- Michal Hocko SUSE Labs