Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp3082423imd; Mon, 29 Oct 2018 01:08:00 -0700 (PDT) X-Google-Smtp-Source: AJdET5cEZD2MkadStqOTpdRX8MqEpdVN4qjvjjox6fl5jyyAYXhLKMeovt8VDEJnlpYvy4G42WI4 X-Received: by 2002:a62:642:: with SMTP id 63-v6mr13958368pfg.190.1540800480644; Mon, 29 Oct 2018 01:08:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540800480; cv=none; d=google.com; s=arc-20160816; b=nazsAQR9V9t0l7ZlH8eyecGH+B+1EDRdCoUsnuQS4KpPdtnona6LJ3i1FnpJfUc7zm 5PnOEBX0ZK9h77p0uj7Rj7VaMTy7+IGeuq9yIcICJsvERlhao1rUBGTdRyS7mfEumil3 4ZLWVchvVCeQqjjMzVG4WPGb5NKx7j5VGZbClM4MosO8nW5LAJVUGoFpq1hzReFj65eV PLnZF8PENL5th2bGMdYyF0bD7cCNKfbYVvHjtxqGwrUlk4qKkUGOgKk+VA8qE40z69UL mQR8UQ/GLEDVukD2RwRX+De+3f2yyg0J040/IXjAwgFYbmL2NiLIB0Tgz4TSdHdiDiiR vOSw== 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=WsMRN+otYi7zeEa8BPXBgBb1HBCCR6zyi3MLOblJfhk=; b=UfQ9ZzRddWgB+tY3FmJ/WPbsBfXfWE3Qr3yJDyKuHQf51oNzPEDsWqBROFZF553X11 Q/69rfkLPkYVacL55uykaJgbjc1Ia9T/Do0GcGNr2DnQMAkMoPke5rc66i17p8QmQBa4 rw381OMtyf5iUE8rpAxm4i8wTVOtfFZrNBnP9tpSHxBOy0ktBPzQcJV9l0oquS2qWIG2 KehewlzJ+lZ+UW3KHRfWjcJEVRZsdvratj1ZLJH6jUnVr1rLfgZN5iDQzHT6T4PiRgy+ Vqcj1K/UFiCHzJwIVZB7Mf7W54FNqvEIEIrIDxOtUbnYhFlbCC0IB2zYcz0rp6UOBh0z 0sWA== 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 e191-v6si20069684pfg.87.2018.10.29.01.07.44; Mon, 29 Oct 2018 01:08:00 -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 S1729427AbeJ2Qym (ORCPT + 99 others); Mon, 29 Oct 2018 12:54:42 -0400 Received: from mx2.suse.de ([195.135.220.15]:42678 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726036AbeJ2Qym (ORCPT ); Mon, 29 Oct 2018 12:54:42 -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 20383B00A; Mon, 29 Oct 2018 08:07:09 +0000 (UTC) Date: Mon, 29 Oct 2018 09:07:08 +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: <20181029080708.GA32673@dhcp22.suse.cz> References: <1540790176-32339-1-git-send-email-miles.chen@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1540790176-32339-1-git-send-email-miles.chen@mediatek.com> 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 13:16:16, miles.chen@mediatek.com wrote: > From: Miles Chen > > The kbuf used by page owner is allocated by kmalloc(), which means it > can use only normal memory and there might be a "out of memory" > issue when we're out of normal memory. > > To solve this problem, use kvmalloc() to allocate kbuf > from normal/highmem. But there is one problem here: kvmalloc() > does not fallback to vmalloc for sub page allocations. So sub > page allocation fails due to out of normal memory cannot fallback > to vmalloc. > > Modify kvmalloc() to allow sub page allocations fallback to > vmalloc when CONFIG_HIGHMEM=y and use kvmalloc() to allocate > kbuf. > > Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation. > > Change since v2: > - improve kvmalloc, allow sub page allocations fallback to > vmalloc when CONFIG_HIGHMEM=y Matthew has suggested a much more viable way to go around this. We do not really want to allow an unbound kernel allocation - even if the interface is root only. 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. > 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