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 AEC0DC25B74 for ; Thu, 16 May 2024 06:23:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 279D66B00DC; Thu, 16 May 2024 02:23:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 202056B0153; Thu, 16 May 2024 02:23:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A3346B0393; Thu, 16 May 2024 02:23:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DA46F6B038F for ; Thu, 16 May 2024 02:23:35 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 53BE1A2429 for ; Thu, 16 May 2024 06:23:35 +0000 (UTC) X-FDA: 82123267590.01.739D25C Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf18.hostedemail.com (Postfix) with ESMTP id E66311C0012 for ; Thu, 16 May 2024 06:23:32 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=Bm8HceVq; spf=none (imf18.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715840613; h=from:from:sender:sender: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:dkim-signature; bh=g2w1SkbEyPJpQsnfvzOqBrv/dXCNXjZK4MBgf8oy0js=; b=7UERXvnWprOB/MNne3mxmVdc3ZgyticHzoBoB+3V+6YrmjDtfrAi3WsEdjIKuVAXaCHj71 hb4sdpDp97a0uNZrJt8tDnl5nLVG1H7N10E8QVHvsemX6+c29bYtzZ4JjZYSjhPmBnbMEC OYMPxRTWBdxhf0H2r2GHdG4MjnTmELM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715840613; a=rsa-sha256; cv=none; b=cDiLGr/RUWDb5SPpZro+eJOYmnTlEN8SEgvVbaG2HTyONa8QxkZqgE9xTyqwkPAtCKf5/o 6PR1KJhvHX5dE+O5q4o8ZYfaxA3t+qry/ZuFps/A7sgRlChtJFtsinz5xKskSIRG32RWvD EYltycUdQa7h1QafD6gLMbjU9UUIUPs= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=Bm8HceVq; spf=none (imf18.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description; bh=g2w1SkbEyPJpQsnfvzOqBrv/dXCNXjZK4MBgf8oy0js=; b=Bm8HceVqhp47IxlSsuijJt8SQS bLkbnOwY7sa1YbKqvj21fFzEn5ZL11P5mLYMSs3hv70sMpjZhL+Kh6tZVXQ373GWnob8ra4BHh5j2 epkU4BdolUYUb+bJ9PWVkeW8YAcbNmdPX/2s+HTnMjl/JyGz7t/+6UrYXwzupU++/QPlktUJ+6jde 3csB6fHF2xZQwPQow4s4Y35A6gKuTdR4SbhHxFOc86tv3Erjag0sWkHTx3PwkU4rw7Lg0l1H5lc/R GYWXhHnqU1yRCyJR2DOnltoRizUGX6bkVeVp0vFV81MuLbXESnTrELGLBUHcM589Iycj5hhO8ee1b VTPG1I2w==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7UWV-00000003r5L-381P; Thu, 16 May 2024 06:23:27 +0000 Date: Wed, 15 May 2024 23:23:27 -0700 From: Luis Chamberlain To: Yu Zhao , David Bueso Cc: Michal Hocko , Dan Williams , John Hubbard , Daniel Gomez , linux-mm , lsf-pc@lists.linux-foundation.org Subject: Re: [LSFMM] automating measuring memory fragmentation Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Stat-Signature: 5acxg8pfkt5wihsa4dt8mxpjxtmutsrk X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E66311C0012 X-HE-Tag: 1715840612-125973 X-HE-Meta: U2FsdGVkX1+wgdCrZraRX7nabHQQqjmlnxUtR/fW4VmbazD5Fdz2vCV1lALkIKu+jSlwiHXPL1h+maNQd53HWrXa+ys1YhWYM0A7KtxKyf5vMNTBrwW9a5ynnU7ui61/qJpuB3qfLPcuw8xMmtgqwgK98oUKvQl34WB1cywITV6f6Dn6HBE4nk909E+OiBF1i+6oi6Zl72IuBmA9ymQQ7nRLWUqBX4Tm63a14xGdwMyVokO6f8oHHhQG0aROZgOKI/gJpS6i7fg+a/AuhC/9cQ8qH6tjQO5wa39lswMdaEQJQtsFaTTmtYPOiUYVR9rBHn7rEWO/SQkiqgZ3a/xYcIN1BlO0mVq/dGt5DDTX3yqFXKDW8TKxQaY1YiwIooGfNhmRl2NXBtzEZiNNOYPT7jEC/+6vXPF6IgjPvZAqSoAz2vcZZeDNBH6RY45lgL9L7ewftP4aG2U5OZxo8e91MZi5ZZbezJV9PhzD9b658WkhsC1wJBYBU1cfAM9Acc0euGKyszwTHVGiLIA5XsbrRZMYFrcNZHrKX/vBVg/s6ovkbs0kLBg5liTs7mrOS0Xp7bHMv4kONWDAJEUx5BLtXAQVhwhSSWh7egBLTedYmmBueY7pcFhYiGVeX+PQPJ9XxnHNJXv/rDdXDBnM92RThKtEu0VejkPADFzcTUKu7JCONQK5SSBhgI1MB9c9jRFcstFqZ8Q1xd1FeLwwyq94QxTyMvCIIhBdGETRejIl0MlJsD9rMSCXSbC5rLxB3dx5F2zdaOIXlUo3YC9JXF675alQq7XS9PNw3PmT5IogMrWMje31XPuv7RX2H9BZNX5SNxisqKI886KZDM4yi1d23eI7jXGbhzwWcJ1llgc0LokoH3G2Ak75wwiV1ZKAoDYx5UerIqSI6e+Fc+8YJWqEk3aOwVPWYZ8mBeimSZLtdY3NBox9ztpbaKit8EksCPuCPFNqulozBUb2cr4fb+j ia7Fcd9d d2OQ2jkoeFiku+76ZbKZNd6aM+0XfLiIMJTJchg9eC868+DBMcyx2IG9iaH1AyBsQ1fPWbZGgycg+ocYqceCjtAF6SimaIRaNuREDb1zneFRl0T38EK60GToM4yAcWeaVblOtiSQ3AYbt7J3kL8rQljxX8SXTcxgVcLPGbnoS4iiMnnX89TdHHUsQMNwKkiIT5AOVWmeBR74RtHvMrhBEYQ2NUTkX181b/kn3OsN++PbiDGZO/hHVek0PCcOzAp2iGi8Y5j2nI6+j21ER3Q/sTLEGvocNOtimm72Dl/1qJWbp2Q/pupHjTZ6kGwSiCAZlKQsR6ZEK52olwdIxM1oFMPX+vXkJEF45/JtYCinCB/cEuQb8KDsJaVgAAcUHEAL5rvW7Twj0qEgmOqllrdAjilDzW0DIjUI6gAf2 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: List-Subscribe: List-Unsubscribe: On Wed, May 15, 2024 at 11:15:58PM -0600, Yu Zhao wrote: > On Wed, May 15, 2024 at 1:34 PM Luis Chamberlain wrote: > > > > RFC to see if we have a breakout session today at LSFMM. > > > > After the TAO talk today it occurred to me that it might make sense > > to review how we're measuring memory fragmentation today. We're looking > > to add automation support into kdevops for this to help compare and > > contrast memory fragmentation behaviour with one kernel against another. > > A while ago, while mTHP was being evaluated I asked genearlly how we > > could measure fragmentation with a simple one value, and John Hubbard > > had one recommendation [0], working that proved we could simplify things > > [1] but we also could just use the existing fragmentation index and only > > consider the values where this is concerned for fragmentation and not > > lack of memory. It begs the question of how folks are measuring memory > > fragmentation today in production, and if they have any desirable > > changes. The first approach being considered is to reproduce the > > workloads Mel Gorman had written and used for mmtests and leverage those > > on kdevops, perhaps modernize them, but before we do so it seems > > reviewing how we measure fragmentation today might be useful to others > > too. > > > > As for mmtests integration into kdevops, first order of business are > > just a few distro-friendly updates [2], for the next steps after that > > though it would be great to review the above. > > > > [0] https://lore.kernel.org/all/5ac6a387-0ca7-45ca-bebc-c3bdd48452cb@nvidia.com/T/#u > > [1] https://lkml.kernel.org/r/20240314005710.2964798-1-mcgrof@kernel.org > > [2] https://lore.kernel.org/kdevops/20240319044621.2682968-1-mcgrof@kernel.org/ > > Please correct me if I'm wrong -- I don't think we can use a single > measure to describe fragmentation in an actionable way. ^^^^^^^^^^ ^^^ Two key words: actionable way. Even in that sense, to say that you need more would suggest that either compaction does not suffice to address memory fragmentation, or that we can improve memory fragmentation through other means. Both are possible, and only measurements can prove that. But my point was not about taking measures in an *actionable way* to address memory fragmentation though, but simply measuring memory fragmentation in environment A and evironment B, to address the question, under which environment is memory fragmentation worse. That said, I am *also* interested in solutions to address memory fragmentation, but that's a secondary step, first I'd like to measure, not take action. It does not mean that evaluating measurements to consider memory fragmentation to evaluate actionable measures are not useful to the single snapshot of memory fragmentation. In fact if more information is better, or we're lacking other sources of measurement of memory fragmentation it'd be great to improve it. As noted in the above URL John Hubbard provided a simple metric recommendation, and I tried to implement it but as the patch in [1] notes the missing semantic would be used folios per order and to add this I thought it would be expensive today from, as per my last review (perhaps I am wrong). Hence my approach to only seek one value and see if its positive, and if so how high. > IMO, we would need at least multiple values, e.g., fragmentation index > for each non-zero order, to describe how fragmented the memory is with > respect to the order of interest. Here you seem to accept you can measure how memory is fragmented with the existing fragmentation index for each order, is that right? Or is it that this is the only tool we have today, but likely we could improve the metric? > Of course we could encode multiple > fragmentation indices into a single value, but that's not really one > measure. If I am not looking for an actionable measure, but just get a single quantifiable metric of "how badly fragmented is this system", is a single value not useful for that purpose? For my purpose, it was about evaluating if the general situation is worse in environment A Vs B, in that world, would a single metric work? > Fragmentation index of an order can tell whether reclaim+compaction > can theoretically result in a free area of that order. Indeed, for my interest it's the positive values, about when a system has memory fragmented. > As an average, > fragmentation index can't tell which actionable unit area, ^^^^^^^^^^ In the A Vs B simple measurement introspection situation one is not taking into consideration an action but just being a silly memory fragmentation voyeur. > e.g., > pageblock, would be the best candidate for reclaim and/or compaction. > That would require a ranking model, e.g., a cost function and weights > for reclaim and compaction operations, and calculations of the cost to > produce a free area of a requested order for each pageblock, i.e., a > 2-dimensional measure > costs_to_produce_free_area[NR_non_zero_orders][NR_pageblocks]. This all makse sense! Luis