Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp140649ybt; Tue, 7 Jul 2020 18:28:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwLMIQTSr3m6oSj6WLKCfqP0ILcr2rcX6bUPzvdnLAQtTscOuz5x8d/f4v/6bvuVuenDNly X-Received: by 2002:a50:8c06:: with SMTP id p6mr25331046edp.146.1594171685589; Tue, 07 Jul 2020 18:28:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594171685; cv=none; d=google.com; s=arc-20160816; b=KCcbv7s5JjamzqxtOngAmTYrBgeCSSx0eipUnXSqu/NWMtnizuXbUAUux5PcNQq5Ey eLtAPvOR6DqDiiMHXVvfT+4xIS0S/HEv2qFmWrJmU6A0pmwzXM9gBRnVzZm3A2YTm4k2 EI592n2N1B7hyFgy6+AzMCDXy8F1v2/LL09P1oKoijKxX7cJNn+kLgLIQAkbjwvriuvc tobIi0i7hhYe/WYpZwk8ln/HVtHAKwjnwb0GCJvf7X10XwFkvWJHNtHj1pyr13tHSBr5 kueb+a1jQWrdupD/T/PKgD4YBGuFaaD+SO+IkKVl0A5J4nU3o53Vlb1CzvRSonD2WBq5 sbJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=xueXT1WuP3G0eQf8E80mn5kaiMzpaC4MoyEEJeh0YNU=; b=H9qLokYlsxus+tYLSWkhvlyGW63n+YnTd+eVCTgbMmp9iOhWEthtRib9pu96cEHADE BmAZJt0J4p15cPAo3h9JkQZ6p85xaEa5FVTMGtiRG60TrgpMyzlzhS/bTqpzMIWeQfjz URoNLS2y9bzcibENmuTtaYCJ5kpBmUcvnvO0+l8tk+vECV4n7l7ua9K29fAs57tZMksR hUjrLl7sF2F1Z3NoneEKuSuR14BIbwoSbdmzpF2lxVUd4jTk0EA0WC0SiQNRNxARD4Q8 BUeOxpdYsFVTFarnCwi9TX9sf7frq1anu7rewoXcNQtgF15uoYEcR/V3Ng/VjPJl63/u ug7Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c26si5809592edy.599.2020.07.07.18.27.43; Tue, 07 Jul 2020 18:28:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729147AbgGHAvr (ORCPT + 99 others); Tue, 7 Jul 2020 20:51:47 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:7821 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728397AbgGHAvq (ORCPT ); Tue, 7 Jul 2020 20:51:46 -0400 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 1B4841322C65DEFE284D; Wed, 8 Jul 2020 08:51:43 +0800 (CST) Received: from [127.0.0.1] (10.57.60.129) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.487.0; Wed, 8 Jul 2020 08:51:33 +0800 Subject: Re: [PATCH] vmalloc: Removing incorrect logs when vmalloc failed To: Uladzislau Rezki , Anshuman Khandual , Tian Tao CC: , , , References: <1594113232-32193-1-git-send-email-tiantao6@hisilicon.com> <5e7885ef-081e-0682-7be7-40eb7712d2c7@arm.com> <20200707132442.GA26493@pc636> From: "tiantao (H)" Message-ID: <3cf13a05-a6b8-aa2f-752d-f9a25a1005f9@huawei.com> Date: Wed, 8 Jul 2020 08:51:33 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20200707132442.GA26493@pc636> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.57.60.129] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ?? 2020/7/7 21:24, Uladzislau Rezki ะด??: > On Tue, Jul 07, 2020 at 03:18:54PM +0530, Anshuman Khandual wrote: >> >> >> On 07/07/2020 02:43 PM, Tian Tao wrote: >>> It is not possible to increase size with vmalloc= in arm64 >>> architecture and it will mislead.however vmalloc return failure >>> is a rare occurrence in 'many architectures including arm64'. >> >> But there is a chance that vmalloc() might work on architectures >> that support 'vmalloc=' command line i.e after a change and this >> information here might be helpful in those cases. >> > Agree. At least i see a few users of it: > > > urezki@pc638:~/data/coding/linux-next.git$ grep -rn early_param ./arch/ | grep vmalloc > ./arch/arm/mm/mmu.c:1152:early_param("vmalloc", early_vmalloc); > ./arch/unicore32/mm/mmu.c:276:early_param("vmalloc", early_vmalloc); > ./arch/x86/mm/pgtable_32.c:86:early_param("vmalloc", parse_vmalloc); > urezki@pc638:~/data/coding/linux-next.git$ > > I'm actually having this problem with the arm64 architecture at centos 7.6 and pagesize is 64K. I followed the prompts and added vmalloc= to the command to increase the size of the vmalloc.and found out it's not worked. It took me some time to find out that this doesn't work for the arm64 architecture, so this log is misleading on arm64. I think it's better not to be prompted than to be prompted incorrectly. I'm sure there will be others with similar problems. So I'd like to solve this problem this time, Please help me with your suggestions. If I change the PATCH to the following, will you accept it? if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit()) +#ifdef CONFIG_ARM64 && CONFIG_XXX + pr_warn("vmap allocation for size %lu failed\n", size); +#else pr_warn("vmap allocation for size %lu failed: use vmalloc= to increase size\n", size); +#endif > Thanks! > > -- > Vlad Rezki > > . >