Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp4312865imd; Mon, 29 Oct 2018 23:06:43 -0700 (PDT) X-Google-Smtp-Source: AJdET5d4vHWNbEaEaoJ46yLdk/yYLb3h7puLT0G6dGNOiGmn4Nx8bC/NlGojI5B3ufoL5SzdwVoL X-Received: by 2002:a62:b24e:: with SMTP id x75-v6mr1640893pfe.148.1540879603546; Mon, 29 Oct 2018 23:06:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540879603; cv=none; d=google.com; s=arc-20160816; b=Bz/QErmtxt8fCzEYUT9oNVXCiawhv7+bS+cM2KdgW/TiY3GIS7VxYX2R6fAxK5aR4V anoqcWSoXfCMBOKojgdFCXN/dP8usWd3IzZVCbtK9KnPme4JqB0Lva6yyQSG1VsDjePV eY9UjTB5uOmx/cw4NJy54ofdneIQiOsxiotRkAQkkniKIyo8xSTCEXI8alDPjf13nV0I p7gFO+ZfDHRVKzkgyTxefENS7tu3aNd22wY6KEBxJwhBNh+a6anbT4SPCcETqukA0tgd cA/FIMnKbgDSvsZaN3BRchvwPGaOMmaMgJOueToaRx60op9qBCCvMbWCJ2RucBKI44VM RlRw== 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=5mYuVYE7lCfKINp1Upq8XEgAoBTD29mpiHsieAEg/X4=; b=rWjJeUpskihNEUv9kPwwYjPAEV3NPJsIxROsaWReLNQjf7Ujj4nugveSikpy1VY1mQ JTZJMrL1wjk7dpMg7zGdQhEbIF1RX5RdLC2aEEedJ1dMUCeJBxiOCwY76XyHof1b8ajZ mXn7YcXGoDFdGdpmxBMoABO06/abK4nTMRS0L+8s9xB9zTkpTCFwi3nMNefjD3tPSo9d G9pZQFjPbvRguwY/hYMJd8BAudafudfJxtWpR4SMhVUB5JCxPSoyRaVVzPbBTlZDhHko YWTW2yOh4RYlQWUnf/D8NFrS9Ih+0YcaTvfDNw7NWuXIFjhaxDN4YQeOllmmr+a/Cw42 By8w== 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 m6-v6si22204762pgg.265.2018.10.29.23.06.27; Mon, 29 Oct 2018 23:06:43 -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 S1726172AbeJ3O6L (ORCPT + 99 others); Tue, 30 Oct 2018 10:58:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:50376 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726050AbeJ3O6K (ORCPT ); Tue, 30 Oct 2018 10:58:10 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 330CBACA7; Tue, 30 Oct 2018 06:06:04 +0000 (UTC) Date: Tue, 30 Oct 2018 07:06:01 +0100 From: Michal Hocko To: Miles Chen 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: <20181030060601.GR32673@dhcp22.suse.cz> References: <1540790176-32339-1-git-send-email-miles.chen@mediatek.com> <20181029080708.GA32673@dhcp22.suse.cz> <20181029081706.GC32673@dhcp22.suse.cz> <1540862950.12374.40.camel@mtkswgap22> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1540862950.12374.40.camel@mtkswgap22> 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 Tue 30-10-18 09:29:10, Miles Chen wrote: > On Mon, 2018-10-29 at 09:17 +0100, Michal Hocko wrote: > > 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. > > > thanks for your comment. It looks like that using vmalloc fallback for > sub page allocation is not good here. > > Your comment gave another idea: > > 1. force kbuf to PAGE_SIZE > 2. allocate a page by alloc_page(GFP_KERNEL | __GFP_HIGHMEM); so we can > get a highmem page if possible > 3. use kmap/kunmap pair to create mapping for this page. No vmalloc > space is used. > 4. do not change kvmalloc logic. If you mean for this particular situation then is this really worth it? I mean this is a short term allocation for root only so you do not have to worry about low mem depletion. If you are thiking in more generic terms to allow kmalloc to use highmem then I am not really sure this will work out. -- Michal Hocko SUSE Labs