From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F2CBC433F5 for ; Wed, 15 Dec 2021 07:56:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7979C6B0071; Wed, 15 Dec 2021 02:56:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 747066B0073; Wed, 15 Dec 2021 02:56:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60F056B0074; Wed, 15 Dec 2021 02:56:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id 520906B0071 for ; Wed, 15 Dec 2021 02:56:49 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0657982D84 for ; Wed, 15 Dec 2021 07:56:39 +0000 (UTC) X-FDA: 78919271718.07.93765A2 Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) by imf14.hostedemail.com (Postfix) with ESMTP id 5B56110000C for ; Wed, 15 Dec 2021 07:56:37 +0000 (UTC) Received: by mail-ua1-f50.google.com with SMTP id o1so39462625uap.4 for ; Tue, 14 Dec 2021 23:56:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cVQUCRhJvXZRgFxiFcRA88PjQcq5cJWHq/xScnHpVHY=; b=EWtbVFy7/FjpAiV2hTh34/42wxztyTTlIIRMIYxHBAlutUg9QHkczZ8Gpw35Bue02Q f9xI39QaDHMTlISt4cmN43Bqf03sqK1Pla0CEeTdq00JW5WILOmGX4RkabqQXaxdYUcy dORkgmmEBnvrLyZ8CIksCrAGykwMsp/OBGhAxySD4SU/yI9AcBPUB+7UnXlqeEdtH2TS O+Yy9gt/1A4tD3NDSSfKdXN0efrA/ng9ZpQ0kUPU6u3kqdnPhzdn+dJ1H8z1slON0nI/ 201cIdKLHMM5nxdBYaEEDO6hUJBnYb5//qeqW+xwMZvngVtZz5N+XxbQF8+WgWONx92f BGkg== X-Gm-Message-State: AOAM533DrIW/rrLdhWRDYW9cKX+Qc87VWqMHyFnTkmb6eWe8Hu+FQGyM S/JZcN/7C1q13M1SxX+jRZeFNPpLQuCwkw== X-Google-Smtp-Source: ABdhPJwRq+7Ii0igrYqBAE4qTs7T/YOuWW1QRIOwx7gxuKN15gHKmmEziYojAucELW0Oo0V6HRNb+Q== X-Received: by 2002:ab0:1303:: with SMTP id g3mr8631958uae.57.1639554997538; Tue, 14 Dec 2021 23:56:37 -0800 (PST) Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com. [209.85.222.51]) by smtp.gmail.com with ESMTPSA id l24sm276277vkk.37.2021.12.14.23.56.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Dec 2021 23:56:37 -0800 (PST) Received: by mail-ua1-f51.google.com with SMTP id w23so39451743uao.5 for ; Tue, 14 Dec 2021 23:56:36 -0800 (PST) X-Received: by 2002:a9f:248b:: with SMTP id 11mr8960109uar.14.1639554996714; Tue, 14 Dec 2021 23:56:36 -0800 (PST) MIME-Version: 1.0 References: <20211130172954.129587-1-vladimir.murzin@arm.com> <20211130172954.129587-2-vladimir.murzin@arm.com> <8c2b4666-cf13-3735-be1e-b8a1c71df113@arm.com> In-Reply-To: From: Geert Uytterhoeven Date: Wed, 15 Dec 2021 08:56:25 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] percpu: km: ensure it is used with NOMMU (either UP or SMP) To: Dennis Zhou Cc: Vladimir Murzin , linux-arch-owner@vger.kernel.org, Linux MM , Tejun Heo , Christoph Lameter , Andrew Morton , Nicholas Piggin , Christoph Hellwig , Arnd Bergmann , Linux-sh list , Rich Felker , linux-riscv Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 5B56110000C X-Stat-Signature: 6ddujbaw5rjhhjtuqjf49awu4ugpmoay Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf14.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.222.50 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com X-HE-Tag: 1639554997-933283 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Dennis, On Tue, Dec 14, 2021 at 9:50 PM Dennis Zhou wrote: > On Tue, Dec 14, 2021 at 09:12:06PM +0100, Geert Uytterhoeven wrote: > > On Tue, Dec 14, 2021 at 8:18 PM Dennis Zhou wrote: > > > On Tue, Dec 14, 2021 at 08:02:58PM +0100, Geert Uytterhoeven wrote: > > > > On Tue, Dec 14, 2021 at 6:26 PM Dennis Zhou wrote: > > > > > On Tue, Dec 14, 2021 at 05:29:22PM +0100, Geert Uytterhoeven wrote: > > > > > > On Wed, Dec 1, 2021 at 12:53 PM Vladimir Murzin wrote: > > > > > > > On 11/30/21 5:41 PM, Dennis Zhou wrote: > > > > > > > > On Tue, Nov 30, 2021 at 05:29:54PM +0000, Vladimir Murzin wrote: > > > > > > > >> Currently, NOMMU pull km allocator via !SMP dependency because most of > > > > > > > >> them are UP, yet for SMP+NOMMU vm allocator gets pulled which: > > > > > > > >> > > > > > > > >> * may lead to broken build [1] > > > > > > > >> * ...or not working runtime due to [2] > > > > > > > >> > > > > > > > >> It looks like SMP+NOMMU case was overlooked in bbddff054587 ("percpu: > > > > > > > >> use percpu allocator on UP too") so restore that. > > > > > > > >> > > > > > > > >> [1] > > > > > > > >> For ARM SMP+NOMMU (R-class cores) > > > > > > > >> > > > > > > > >> arm-none-linux-gnueabihf-ld: mm/percpu.o: in function `pcpu_post_unmap_tlb_flush': > > > > > > > >> mm/percpu-vm.c:188: undefined reference to `flush_tlb_kernel_range' > > > > > > > >> > > > > > > > >> [2] > > > > > > > >> static inline > > > > > > > >> int vmap_pages_range_noflush(unsigned long addr, unsigned long end, > > > > > > > >> pgprot_t prot, struct page **pages, unsigned int page_shift) > > > > > > > >> { > > > > > > > >> return -EINVAL; > > > > > > > >> } > > > > > > > >> > > > > > > > >> Signed-off-by: Vladimir Murzin > > > > > > > > > IIRC, RISC-V also have SMP+NOMMU, so adding them as well. > > > > > > > > > > > > I had seen the j-Core thread, but completely forgot about > > > > > > Canaan K210 (RV64 SMP+NOMMU). > > > > > > > > > > > > This became commit 3583521aabac76e5 ("percpu: km: ensure it is used > > > > > > with NOMMU (either UP or SMP)"). And now booting K210 prints: > > > > > > > > > > > > percpu: wasting 10 pages per chunk > > > > > > > > > > > > a) Is this bad? > > > > > > > > > > It's not great.. Can you share the line on boot with the following > > > > > prefix: pcpu-alloc [1]. > > > > > > > > There are no such lines. > > > > "make mm/percpu.i mm/percpu.s" and inspecting the generated files, > > > > and vmlinux, proves the code is there. But apparently it's not called. > > > > > > > > So there may be no issue on my system? > > > > > > I might be missing something, but that can't be right. Percpu calls > > > pcpu_dump_alloc_info() from pcpu_setup_first_chunk() which is called by > > > both embed/page first chunk code. > > > > > > Ummm. That can't be right. Percpu call pcpu_dump_alloc_info() from > > > pcpu_setup_first_chunk() which everyone should call. On my machine: > > > > > > $ dmesg | grep "pcpu-alloc" > > > [ 0.065118] pcpu-alloc: s184320 r8192 d28672 u262144 alloc=1*2097152 > > > > Doh, it wasn't printed to the console, due to KERN_DEBUG. Dmesg > > does have it: > > > > <7>[ 0.000000] pcpu-alloc: s15520 r0 d29536 u45056 alloc=11*4096 > > <7>[ 0.000000] pcpu-alloc: [0] 0 [0] 1 > > > > I see, so what's happening is we're allocating 11 pages * 2, and due to > percpu-km we round up to a contiguous 32 pages for backing pages. This > results in the warning of wasting 10 pages. Given the size of the static > region, I'm not too worried for now. I can't imagine the config would > use that much percpu memory. > > We can massage the discrepancy for-v5.17. Basically in percpu-km, we > align to 4k even though our allocation gets rounded up to the next power > of 2. I don't have a lot of bandwidth right now, but I might be able to > think about it over the next few weeks. Note that K210 has only 8 MiB of SRAM, so wasting 10 pages means wasting 0.5% of RAM. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds