Received: by 10.223.185.116 with SMTP id b49csp8498904wrg; Fri, 2 Mar 2018 02:56:25 -0800 (PST) X-Google-Smtp-Source: AG47ELtMr0SSi7h8DstGJvcAa7EyEUE/lRQUvK35lU+cLdIeXASmqXHSu3ZPT4jicMs/mLyUGZQE X-Received: by 10.98.65.198 with SMTP id g67mr5259291pfd.127.1519988185680; Fri, 02 Mar 2018 02:56:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519988185; cv=none; d=google.com; s=arc-20160816; b=I5drOJscUHGXf/o1TeoDa0NUjQAzbeVlFuWHVsyYqMcX6q0pU04Q7s2z7ph1PwGpK2 d9rEqqsuSe2RdcR4dzcwAkqviB63q+g/PpUD+GR4RZyLlnOibJ/e9GWd1EifkoDFwIGW +nbsQjMSn7Y3lqmcNAYERzULEmjLK/9mPYEVNjUrfNuH9sNuwN+brX6dQyv03ZKlNE9T bKj4LxjdKu10ZqRckPtiXExkZXnsj/Err8DNQfGcoTdNgch+imdx7PffRs9BUkzoo1IV HONrAe9nKwf7TJ8VnjEP4TocoiCIaNc0eKLaisLtOAspNtvXVI+KbGrrHAhWjMJrO7Q5 ZwVA== 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=6TX2n9gnb/PPvprUuE86LCZ+f6HQ0NtLqURTvx6HMZc=; b=BL/5WIcCzC7rNlvwlFflaWrpbDY+VRWKaL3IKGrWsOVBYpBM2GUy6NEfghY7A8XGmR mfpIg0Zr4MOb8QPoce8LMnmCQIFwHGTKtbvE9Pxh9PauXdr1xj5y4fdy8/YsNXxRjbFB yYCIWX8a348/ZmOziKhztqrew465iqfvty/xvdmdW8nRoZ6FdD3aC6cpr2VsZzz23pf4 /XxJ7vO7AFBXjHa5y1g0aKejgIl/wJWK5abOAz10bLs42OxtkEAemgkXQxk1JgK/0V29 3eMICIkYoyC2PGi03O5xSwWqQ26qv+nhTm9fh+sgWPFYNSEJ0gq18iGpg/U5T6znVfnf 6P0w== 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 y12si3823203pgv.251.2018.03.02.02.56.10; Fri, 02 Mar 2018 02:56:25 -0800 (PST) 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 S1426704AbeCBKy4 (ORCPT + 99 others); Fri, 2 Mar 2018 05:54:56 -0500 Received: from mail-ot0-f176.google.com ([74.125.82.176]:38115 "EHLO mail-ot0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423905AbeCBKyw (ORCPT ); Fri, 2 Mar 2018 05:54:52 -0500 Received: by mail-ot0-f176.google.com with SMTP id 95so8359365ote.5 for ; Fri, 02 Mar 2018 02:54:52 -0800 (PST) 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=6TX2n9gnb/PPvprUuE86LCZ+f6HQ0NtLqURTvx6HMZc=; b=NxZfCITEUK0lP2CkCogO6WjPTarMojDBMwKMwKuD+zH5lDw16wCdaiWg8FdKG8vnYj r/3luz/cYzoHU03a32Jo/+jYcRE8BHi+05XoP2HN+la2W/0JeXhWUNyUaR44hmgJcEMo qaWmmUWFNKu9M9dT61NX3fyISpeNLXG0JtSyLZQdIpjGvrKCBDX5o1vbFedugt6dcNpC yQm8vX9BS/xeIiaqZPW8awdWaNIYBGV7aRnTnNryEYyRzapc9azBpY2MZ57TBnimJWD4 nez2GOGz226ae27d27uopep9QftAvIV6A27hI3do6G/J8lD1hPoHcuCSrpyh1agJYT4b d0rQ== X-Gm-Message-State: AElRT7EEgYT9gzFwbYqJv67CefWoDXqmp9TkOd/GSOUWCaPcTWmstvsR wljb0zvK9P54rZoqBxSufUpC45kufmiTXq1ZwWVpYBFaIk4= X-Received: by 10.157.56.9 with SMTP id i9mr3926896otc.90.1519988091733; Fri, 02 Mar 2018 02:54:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.57.246 with HTTP; Fri, 2 Mar 2018 02:54:51 -0800 (PST) In-Reply-To: References: <1519908465-12328-1-git-send-email-neelx@redhat.com> <20180301131033.GH15057@dhcp22.suse.cz> <20180301152729.GM15057@dhcp22.suse.cz> From: Daniel Vacek Date: Fri, 2 Mar 2018 11:54:51 +0100 Message-ID: Subject: Re: [PATCH] mm/page_alloc: fix memmap_init_zone pageblock alignment To: Michal Hocko , Paul Burton Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Mel Gorman , Pavel Tatashin , stable@vger.kernel.org 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 Thu, Mar 1, 2018 at 5:20 PM, Daniel Vacek wrote: > On Thu, Mar 1, 2018 at 4:27 PM, Michal Hocko wrote: >> It is still not clear why not to do the alignment in >> memblock_next_valid_pfn rather than its caller. > > As it's the mem init which needs it to be aligned. Other callers may > not, possibly? > Not that there are any other callers at the moment so it really does > not matter where it is placed. The only difference would be the end of > the loop with end_pfn vs aligned end_pfn. And it looks like the pure > (unaligned) end_pfn would be preferred here. Wanna me send a v2? Thinking about it again memblock has nothing to do with pageblock. And the function name suggests one shall get a next valid pfn, not something totally unrelated to memblock. So that's what it returns. It's the mem init which needs to align this and hence mem init aligns it for it's purposes. I'd call this the correct design. To deal with the end_pfn special case I'd actually get rid of it completely and hardcode -1UL as max pfn instead (rather than 0). Caller should handle max pfn as an error or end of the loop as here in this case. I'll send a v2 with this implemented. Paul> Why is it based on memblock actually? Wouldn't a generic mem_section solution work satisfiable for you? That would be natively aligned with whole section (doing a bit more work as a result in the end) and also independent of CONFIG_HAVE_MEMBLOCK_NODE_MAP availability. >> -- >> Michal Hocko >> SUSE Labs