Received: by 10.213.65.68 with SMTP id h4csp1329339imn; Wed, 21 Mar 2018 08:07:18 -0700 (PDT) X-Google-Smtp-Source: AG47ELvprp3pveeYs8lpMqhJ+co93b4TQuaQBpjnFrQLHo2dbpiHs9S1DlXFlqeR2lZritw13Gzf X-Received: by 2002:a17:902:ac96:: with SMTP id h22-v6mr20729094plr.93.1521644838598; Wed, 21 Mar 2018 08:07:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521644838; cv=none; d=google.com; s=arc-20160816; b=h9umMcJUob5kaIrur89N/SPVqIKtubpifwMhWswgJtuhPBgdgPAdZ4J/bbbUD74IXL Y+OxbgHvzGiMKjw22IOtT4M32QagXBo0XjqgBh1sQ5D4GJ/Vz03Jn01Vff3t5hx4sYAD eKv5l11Zjn2Pq+WhJQrqaqUx/5zjXoqk/mTSOEujMic24JjIdO6gUTRefQLkF5uXIamO F4h3reE/BSVDmzNFBy5ZphRzVGmn1kW+l9ALR2msEU1wFszgz5uEhxLCH1J82INLYeDd 3V0VR/wziNDfuegKhQGGzpOJy/IABV1xHhpo5P9b9rbdnMi0mC1yYcnSEN+pJ0TH2TD5 pSww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=Ox2U4KIcjn0iuF8e2uZhL10roxGPbbLhl6hCpn8OGOE=; b=XhrdP74QrFOSQ3PB8Mu9+rcTth/nzKz6LF8S/3bhE+ykWpXJojL2B5TYm/b/Hp8e9Y 11JBtsNghCaO6kn7hkzNosSFSME28CtpFbMrGNhJnK33jtX0VgzEY0D+h2lNQkrlnWyS nObFtmcBzinVAHo8kegZpRnJknO3PTNUbCR7l6BGzbE1naWPfV2eQ75PLbSJixMphDDT Ag9dbJza1AuwAUHa3sLB85Djzx/SLU3d2MzLzpzZTtCpi3ZBKj9oHezaFWe0yc9mkDen yPUXwdXVMJUvAY9XNpuQFkvDgvTi6KK7VWF1LnIOijePzvLKxDyGTC0esgUcpghGGMjm 0kkA== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a60-v6si3984100pli.13.2018.03.21.08.07.03; Wed, 21 Mar 2018 08:07:18 -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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752564AbeCUPFB (ORCPT + 99 others); Wed, 21 Mar 2018 11:05:01 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:40393 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752116AbeCUPE6 (ORCPT ); Wed, 21 Mar 2018 11:04:58 -0400 Received: by mail-oi0-f68.google.com with SMTP id c12-v6so4562147oic.7 for ; Wed, 21 Mar 2018 08:04:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ox2U4KIcjn0iuF8e2uZhL10roxGPbbLhl6hCpn8OGOE=; b=c/p8pL/Wpp5M+SlPL5w5jcjYDx9xItgJoKGKcV9Oa2pJ3ivPB1dulcduJ92kEYBTo0 BJCkUM3Xvu+S5ttUhVRQX8v1sD/Ysqs01KbAP2+IcefkNbcmIxoaOXhT2W1qb30cAtlk kbhkmrBwFwGeZoqvrA/OIPkDJt+aH5uVVu4I0wYtJ5VWAKMCV8gaGJRz8bed/jHCvBfP 8211flfzeJCDlBYlwPK4+Gp7x+ZHNMXp6alORnRk0yWuRkzcJK9aIMa72Soji9HN8d4A s51c5C//Q+X2tU9P/kYr6U+5Lcf7J2RevShmgkIQfzVAfXozeOi+ZSExDOasybFRQoS1 QE9g== X-Gm-Message-State: AElRT7GmEbC6iTDbE80KauCzX7vpJEx/++wWlNpfI/YxFKQD2xu3UB+o MWOXu9GCofSG6MZU2NCi+g1YaItM+Jr7WXiDEnzXCA== X-Received: by 10.202.104.170 with SMTP id o42mr8936811oik.296.1521644697723; Wed, 21 Mar 2018 08:04:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:39f6:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 08:04:57 -0700 (PDT) In-Reply-To: <3f208ebe-572f-f2f6-003e-5a9cf49bb92f@gmail.com> References: <1521619796-3846-1-git-send-email-hejianet@gmail.com> <1521619796-3846-2-git-send-email-hejianet@gmail.com> <3f208ebe-572f-f2f6-003e-5a9cf49bb92f@gmail.com> From: Daniel Vacek Date: Wed, 21 Mar 2018 16:04:57 +0100 Message-ID: Subject: Re: [PATCH 1/4] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn() To: Jia He , Ard Biesheuvel Cc: Andrew Morton , Michal Hocko , Catalin Marinas , Mel Gorman , Will Deacon , Mark Rutland , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Pavel Tatashin , Daniel Jordan , AKASHI Takahiro , Gioh Kim , Steven Sistare , Eugeniu Rosca , Vlastimil Babka , open list , linux-mm@kvack.org, James Morse , Steve Capper , x86@kernel.org, Greg Kroah-Hartman , Kate Stewart , Philippe Ombredanne , Johannes Weiner , Kemi Wang , Petr Tesarik , YASUAKI ISHIMATSU , Andrey Ryabinin , Nikolay Borisov , Jia He Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 21, 2018 at 1:28 PM, Jia He wrote: > > On 3/21/2018 6:14 PM, Daniel Vacek Wrote: >> >> On Wed, Mar 21, 2018 at 9:09 AM, Jia He wrote: >>> >>> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns >>> where possible") optimized the loop in memmap_init_zone(). But there is >>> still some room for improvement. E.g. if pfn and pfn+1 are in the same >>> memblock region, we can simply pfn++ instead of doing the binary search >>> in memblock_next_valid_pfn. >> >> There is a >> revert-mm-page_alloc-skip-over-regions-of-invalid-pfns-where-possible.patch >> in -mm reverting b92df1de5d289c0b as it is fundamentally wrong by >> design causing system panics on some machines with rare but still >> valid mappings. Basically it skips valid pfns which are outside of >> usable memory ranges (outside of memblock memory regions). > > Thanks for the infomation. > quote from you patch description: >>But given some specific memory mapping on x86_64 (or more generally >> theoretically anywhere but on arm with CONFIG_HAVE_ARCH_PFN_VALID) > the >> implementation also skips valid pfns which is plain wrong and causes > >> 'kernel BUG at mm/page_alloc.c:1389!' > > Do you think memblock_next_valid_pfn can remain to be not reverted on arm64 > with CONFIG_HAVE_ARCH_PFN_VALID? Arm64 can benefit from this optimization. I guess this is a question for maintainers. I am really not sure about arm(64) but if this function is correct at least for arm(64) with arch pfn_valid(), which is likely, then I'd say it should be moved somewhere to arch/arm{,64}/mm/ (init.c maybe?) and #ifdefed properly. Ard? > Cheers, > Jia