Received: by 10.223.185.116 with SMTP id b49csp29788wrg; Tue, 13 Feb 2018 15:57:51 -0800 (PST) X-Google-Smtp-Source: AH8x225muR3w5/WDfEvvM/Bin+Z4hXvlK46ydwr9c9gYMsJ18HXAOwctqyZG5rEuGRkMoq3E9Qmb X-Received: by 10.99.116.18 with SMTP id p18mr2265336pgc.77.1518566271511; Tue, 13 Feb 2018 15:57:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518566271; cv=none; d=google.com; s=arc-20160816; b=VapJN3ZFk8XCrQfnnDXa85aaZm/d3LjGCCnA8coJTmcSRdGoWOuf4apdVfADqZ5UHk SL9p2zTqMyIaMOsgd1iCNKCN9NQ6VktstEZY3Qn/a5+si+ZrHHnzCLoajYHuiuwfWhoC 2qcnVRH+KWDFarnfBBVgG6NTzjpy2r1yE9SoxNOGQ+oNkFhsZGK0B7S2utM8N2jETqHE DAHsTSrbBBdtv95OxtVTOt1eWY2sz3Wm6bnzvsZGJ2jlpsPpYulHwjYvJ9oKPa6RrLUs xmXod05E9BYB6pcTkjLN6QwxE0p9F7jZYvJiN0KVTrG0l+z73l/azjYcKaozlm3ZCdDO gaaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=yvoUzyyLKX8+GJzEEUGWR7gWh5MoIMgTsvG2wSBb5A0=; b=ZvgK+w+e4vuNQ8NrBFttP9SE3mkk5BgnpFwzFViRJ4u2Zq5sZrYWYIq8R2GM/Cvpz3 4ea9KK/CsFbN+CjHPwdyejbD7qGOx3trh3bugc6XAYzLAdUi15BNAY+qjcd5q13U9H3A tDWxOUOhjq08EExhSSp+1/V7V1Rb2IMg0R+A4b5wutNw3waflC+TCAicnE74DitvZBpm 1pYU0UcjfNiuw+tWocqZ/z+X2Ao7Me2cnhdsMsLgx6Y9Z999wu8+yhKuW8i0WwRJ+04G qdRPI7KupWlArycUU+sIcZGGRz1ENtkAx6XQdZUvAKubpgqlXtF3/vI6Z7vrmSqaVeXH +FOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZrOv99mt; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n9si4051054pge.307.2018.02.13.15.57.36; Tue, 13 Feb 2018 15:57:51 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=ZrOv99mt; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966326AbeBMXzQ (ORCPT + 99 others); Tue, 13 Feb 2018 18:55:16 -0500 Received: from mail-it0-f46.google.com ([209.85.214.46]:51685 "EHLO mail-it0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966108AbeBMXzN (ORCPT ); Tue, 13 Feb 2018 18:55:13 -0500 Received: by mail-it0-f46.google.com with SMTP id 193so10351703iti.1 for ; Tue, 13 Feb 2018 15:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=yvoUzyyLKX8+GJzEEUGWR7gWh5MoIMgTsvG2wSBb5A0=; b=ZrOv99mtzYbqdPBAjx0jO/8zYMvZE1rVp39FUvAZ15+8B5QwYeB9/N+KIjxRu99eZW rjFtiDg2FX5nyVIcPeHtBr1U1zxyFbvXQ4ji5ohA9X6YcmUAGYwBqDykbCR/l2cQpBnP ODFXfnAXontOsmR5APvNfmylLUoqsr0NNkzI8wINlEtvoKO1vxDmSuwOry/VYmOp+ST7 heHb/zsuyWp9ikJZDAt94LSqt8rIzwFS14xEeQBHWYomMMH3lvuKiIV6T2dcIvvKIDrg 3RXHxL2epODjni9Nwg2p1aHFQrpL95Wf2r1uBL2MPafDjhXp/7EDhEak60r/Ys2hgP+V RAqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=yvoUzyyLKX8+GJzEEUGWR7gWh5MoIMgTsvG2wSBb5A0=; b=gA3i1AyNyC/pOjxPGppbtzwznSIh+KmGeYI3cIAosDdWQuIEBzg1hsJYscbBwBnq1N mVuzZopneKP7NX9fL1czR9o/PgWtLHHLPLmm2QgRc88FX6eOrcfQ/Frkh3j8qmBT5BPW /zpE4zv4X2EObT1QeLv2NVXZb082LC3rfOEnzR3gTcmk5BUsFW+lHsWrnE3xn9slmxeZ FySPi1aQTml/ulnmx4wc18F25+Yud7BJbN3EYil/3D9g9Obq072vlToOmIsCUFnOu479 5W8lHQKOZuSUyZxttLRP9+134y1Itw6w3nxWZY91Nem/ePfB4qIduM9LI1o3hoO80xTj Awfw== X-Gm-Message-State: APf1xPDfoKh4v0WChQbYWCVS9bmZnqJsvQIGmQ49JLafdP6mvQPboZHs mWTXWoho7N2sdJRzUZ7PSYVAbT5fUOA= X-Received: by 10.36.20.81 with SMTP id 78mr3879770itg.1.1518566112902; Tue, 13 Feb 2018 15:55:12 -0800 (PST) Received: from [2620:15c:17:3:dc0:1ee9:9ea3:7c4f] ([2620:15c:17:3:dc0:1ee9:9ea3:7c4f]) by smtp.gmail.com with ESMTPSA id v144sm11529314itc.0.2018.02.13.15.55.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Feb 2018 15:55:12 -0800 (PST) Date: Tue, 13 Feb 2018 15:55:11 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Andrew Morton cc: Jonathan Corbet , Vlastimil Babka , Mel Gorman , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org Subject: Re: [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent In-Reply-To: <20180213154607.f631e2e033f42c32925e3d2d@linux-foundation.org> Message-ID: References: <20180213154607.f631e2e033f42c32925e3d2d@linux-foundation.org> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Feb 2018, Andrew Morton wrote: > > Both kernelcore= and movablecore= can be used to define the amount of > > ZONE_NORMAL and ZONE_MOVABLE on a system, respectively. This requires > > the system memory capacity to be known when specifying the command line, > > however. > > > > This introduces the ability to define both kernelcore= and movablecore= > > as a percentage of total system memory. This is convenient for systems > > software that wants to define the amount of ZONE_MOVABLE, for example, as > > a proportion of a system's memory rather than a hardcoded byte value. > > > > To define the percentage, the final character of the parameter should be > > a '%'. > > Is this fine-grained enough? We've had percentage-based tunables in > the past, and 10 years later when systems are vastly larger, 1% is too > much. > They still have the (current) ability to define the exact amount of bytes down to page sized granularity, whereas 1% would yield 40GB on a 4TB system. I'm not sure that people will want any finer-grained control if defining the proportion of the system for kernelcore. They do have the ability with the existing interface, though, if they want to be that precise. (This is a cop out for not implementing some fractional percentage parser, although that would be possible as a more complete solution.)