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 X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 919E3C33CA9 for ; Mon, 13 Jan 2020 23:02:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4714D207FF for ; Mon, 13 Jan 2020 23:02:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="T3zcpcpy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4714D207FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EA1F88E0005; Mon, 13 Jan 2020 18:02:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E51D58E0003; Mon, 13 Jan 2020 18:02:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF26D8E0005; Mon, 13 Jan 2020 18:02:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id B2F978E0003 for ; Mon, 13 Jan 2020 18:02:05 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 52598181AC9C6 for ; Mon, 13 Jan 2020 23:02:05 +0000 (UTC) X-FDA: 76374135810.07.slope66_4c5f9c3393614 X-HE-Tag: slope66_4c5f9c3393614 X-Filterd-Recvd-Size: 7186 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Mon, 13 Jan 2020 23:02:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578956524; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bm3U0v5B+3wtviHg6/7svBiiNOgf1JGGaGbNrH7xPhk=; b=T3zcpcpyT+vg5ZqwQE0Le0op+AYqkzRDe7l89PJ3wCwR+QsTvcR9qyAuLg8iKLWdL7W/ig gPro2mX43OeEHlEnximtUMzN7S+HOfEh5k+cBW+gqbXAXrDeRYxHJaUJyaqPs9nPd1kLL8 E/crrPKQ5QtdsDvmClF1D2JH1RyiafM= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-63-jNqmfPYFMnSnksdbsOQH5A-1; Mon, 13 Jan 2020 18:02:03 -0500 Received: by mail-wr1-f70.google.com with SMTP id u12so5656836wrt.15 for ; Mon, 13 Jan 2020 15:02:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=5fL1RUVxKn4V2Ga2cRKwS4hMy9dSfducYFMZLP5PZMc=; b=ffuVXODagxFG8S5wCsK6fLP+EdQUGm7sz1hL5SI2q76KeOa4Bc+3Tv7bEfb/84wv9Z 7s1sHXjoIbaNCOmjReBd0QPWyfUNuhNqhCjYCRMruNqGf6EERsjX0N/dQcRdHSLe/v8E 7kXPxqsG3C4/aD+Ycbx0iTOVFi+qG95PtH2SjdUAa+OCpja/mobHCasxZh6zmFXp301q aVWFQPfqDPh4ChL7LjBNV7hJEgJ+WrsAlSJIiglzXsR9CMvr/NdO7P4ZXwmiyKJ/s1f3 YmmmOzFCBEut0oOH4OqiCRpkjlOk73dPNC5Sg53Z9VSjVY0oSBY9nm+JQ4/CpF4lq9vY j1XQ== X-Gm-Message-State: APjAAAXPk+hBOg8YHM/on4eZ8H5FNs+CQatwY7L2mc7INAdLopqoN4oO xVRU3fAYtNNstmm7kfJAMBY1zBa7k2fP1vCB8eu3qllZMLJcIJZR28Tt5AiswFr34cxtneCZrNY ginVZer9CSR4= X-Received: by 2002:a05:600c:1003:: with SMTP id c3mr22551696wmc.120.1578956521980; Mon, 13 Jan 2020 15:02:01 -0800 (PST) X-Google-Smtp-Source: APXvYqz9SqrbRJ1amVPbv6RQ8+6k23HI2AviInNnXyBSjBFNCQ72/q/DmkvdohlkJoL+leSPqUNaAA== X-Received: by 2002:a05:600c:1003:: with SMTP id c3mr22551679wmc.120.1578956521786; Mon, 13 Jan 2020 15:02:01 -0800 (PST) Received: from [192.168.3.122] (p5B0C617C.dip0.t-ipconnect.de. [91.12.97.124]) by smtp.gmail.com with ESMTPSA id s65sm16655673wmf.48.2020.01.13.15.02.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jan 2020 15:02:01 -0800 (PST) From: David Hildenbrand Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v1 2/2] mm: factor out next_present_section_nr() Date: Tue, 14 Jan 2020 00:02:00 +0100 Message-Id: References: <0B77E39C-BD38-4A61-AB28-3578B519952F@redhat.com> Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Michal Hocko , Oscar Salvador In-Reply-To: <0B77E39C-BD38-4A61-AB28-3578B519952F@redhat.com> To: "Kirill A. Shutemov" X-Mailer: iPhone Mail (17C54) X-MC-Unique: jNqmfPYFMnSnksdbsOQH5A-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: > Am 13.01.2020 um 23:57 schrieb David Hildenbrand : >=20 > =EF=BB=BF >=20 >>> Am 13.01.2020 um 23:41 schrieb Kirill A. Shutemov : >>>=20 >>> =EF=BB=BFOn Mon, Jan 13, 2020 at 03:40:35PM +0100, David Hildenbrand wr= ote: >>> Let's move it to the header and use the shorter variant from >>> mm/page_alloc.c (the original one will also check >>> "__highest_present_section_nr + 1", which is not necessary). While at i= t, >>> make the section_nr in next_pfn() const. >>>=20 >>> In next_pfn(), we now return section_nr_to_pfn(-1) instead of -1 once >>> we exceed __highest_present_section_nr, which doesn't make a difference= in >>> the caller as it is big enough (>=3D all sane end_pfn). >>>=20 >>> Cc: Andrew Morton >>> Cc: Michal Hocko >>> Cc: Oscar Salvador >>> Cc: Kirill A. Shutemov >>> Signed-off-by: David Hildenbrand >>> --- >>> include/linux/mmzone.h | 10 ++++++++++ >>> mm/page_alloc.c | 11 ++--------- >>> mm/sparse.c | 10 ---------- >>> 3 files changed, 12 insertions(+), 19 deletions(-) >>>=20 >>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h >>> index c2bc309d1634..462f6873905a 100644 >>> --- a/include/linux/mmzone.h >>> +++ b/include/linux/mmzone.h >>> @@ -1379,6 +1379,16 @@ static inline int pfn_present(unsigned long pfn) >>> return present_section(__nr_to_section(pfn_to_section_nr(pfn))); >>> } >>>=20 >>> +static inline unsigned long next_present_section_nr(unsigned long sect= ion_nr) >>> +{ >>> + while (++section_nr <=3D __highest_present_section_nr) { >>> + if (present_section_nr(section_nr)) >>> + return section_nr; >>> + } >>> + >>> + return -1; >>> +} >>> + >>> /* >>> * These are _only_ used during initialisation, therefore they >>> * can use __initdata ... They could have names to indicate >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >>> index a92791512077..26e8044e9848 100644 >>> --- a/mm/page_alloc.c >>> +++ b/mm/page_alloc.c >>> @@ -5852,18 +5852,11 @@ overlap_memmap_init(unsigned long zone, unsigne= d long *pfn) >>> /* Skip PFNs that belong to non-present sections */ >>> static inline __meminit unsigned long next_pfn(unsigned long pfn) >>> { >>> - unsigned long section_nr; >>> + const unsigned long section_nr =3D pfn_to_section_nr(++pfn); >>>=20 >>> - section_nr =3D pfn_to_section_nr(++pfn); >>> if (present_section_nr(section_nr)) >>> return pfn; >>> - >>> - while (++section_nr <=3D __highest_present_section_nr) { >>> - if (present_section_nr(section_nr)) >>> - return section_nr_to_pfn(section_nr); >>> - } >>> - >>> - return -1; >>> + return section_nr_to_pfn(next_present_section_nr(section_nr)); >>=20 >> This changes behaviour in the corner case: if next_present_section_nr() >> returns -1, we call section_nr_to_pfn() for it. It's unlikely would give >> any valid pfn, but I can't say for sure for all archs. I guess the worst >> case scenrio would be endless loop over the same secitons/pfns. >>=20 >> Have you considered the case? >=20 > Yes, see the patch description. We return -1 << PFN_SECTION_SHIFT, so a n= umber close to the end of the address space (0xfff...000). (Will double che= ck tomorrow if any 32bit arch could be problematic here) ... but thinking again, 0xfff... is certainly an invalid PFN, so this shoul= d work just fine. (biggest possible pfn is -1 >> PFN_SHIFT) But it=E2=80=98s late in Germany, will double check tomorrow :)