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 DB69BC25B74 for ; Thu, 16 May 2024 21:32:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E2F76B0085; Thu, 16 May 2024 17:32:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 093D36B0088; Thu, 16 May 2024 17:32:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9CDD6B0089; Thu, 16 May 2024 17:32:53 -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 C9E796B0085 for ; Thu, 16 May 2024 17:32:53 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7DE2C1A0E72 for ; Thu, 16 May 2024 21:32:53 +0000 (UTC) X-FDA: 82125559026.06.568A4E9 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf08.hostedemail.com (Postfix) with ESMTP id 86854160005 for ; Thu, 16 May 2024 21:32:51 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lr6hcsKO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of kmanaouil.dev@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=kmanaouil.dev@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715895171; h=from:from: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Qgd6RtaAvezTUzJoyoPMk1m+HTaq0Wz4HgWlV5JhiwI=; b=7Rk8cE667uLCnXdyESOs1X44Iqcqec4nvVqthE01DneWc9jNjmwcmtI48RWBfeXtKRdFxY chCOLDwE9NqiOiOj9J9BtWEnWYsp7w1BgsuBrtb41SYxH9ezm4TqCq0mPFQUKgLPEZJHbo nERczGw42l6TeE2SDfI7S6CBRKBlQiM= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lr6hcsKO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of kmanaouil.dev@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=kmanaouil.dev@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715895171; a=rsa-sha256; cv=none; b=IUXzEZafSo/OqMSEzS4eShUl8KlzERNkUH+HdaPr7b6ps7GaXp6EpJjPm+XWlVjnR98h3k yNCmQyNEsB5TmJjfhWKIjDcrq0JmaFgVmrKU5U/wnHhywOUcnW+K6Cq8WRyxPNhMz6cH4U 9rFDcti9VM5hKDheA6/GOe+NDJRJHJk= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2e1e8c880ffso2453971fa.2 for ; Thu, 16 May 2024 14:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715895170; x=1716499970; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Qgd6RtaAvezTUzJoyoPMk1m+HTaq0Wz4HgWlV5JhiwI=; b=lr6hcsKOHxC9iE4Inr/oEwHpl9meTB+HLQmlZoCf+jL/ZtKZyRBvEihe0bR+OTTy3J QS5KtY3Z/rke99/3N6V4YUhSOlRzjEBVSZZITlOaLwsHp43VPHdhone1xJhLnrIYpeuC 5s9gl4TE9uRwJ4JMmDjYw/Lipzv7U3RbFwlY9RD3m/2v+a3HRiPGXNZDyzL0UX9ISIIK AqM7YguNoYuQjf3iU9y8xTX4TLvHDuWRdNL2pObeTfdtGoRcVeS0kr6iItTW9T9iiBTu 0iaG9KaCu9ikcX6g1zmkJsblKXLmnTjfylvbxcOwb2w+L4+LL7zB3tjohhkxhAmbFiGG q7Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715895170; x=1716499970; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Qgd6RtaAvezTUzJoyoPMk1m+HTaq0Wz4HgWlV5JhiwI=; b=ZH1AolYe6WqmHchcGeBZ1zjPAI96d1yBn8uGk7ttnyGc7dWfVKQXnXkMG5qT04h5/e toeAaLWIzP8lmaERe4fgdY9h0vcoteN7NM9r2tVSKhqB6j2vL/owYVvvKws/LzRQl6Zv 0peaWgw4rpGQ3iyrIG5Pz8fSVCH/u3c+x36ImyIZm/J3Ikhmut/12cRQGce1dHQ3SFRW PPVlwHLZdan1GHY05Ne2agZ35Jv5CaHfmquOd0VcTRkRq0vbyN31XpFGL36HSy452D8K O5Wsh1RjMPF80iZjBLQCEdfM5t8O45faOQsh2VjUEsRbZhXjiRy552T3gMbGNVSlJvH1 WJug== X-Forwarded-Encrypted: i=1; AJvYcCXMgvsUp3YLXYgB2RaXme80UxH1/dW4QqyeMi/e6JlxjydVKNPRGGvA7yqGWtl/QaIC8d8uNKLy9Z66oTFviabyoIQ= X-Gm-Message-State: AOJu0YzIbcD78nqiNivKM3wfZ4hvX9FobHLJJoHZnjCmNv9kIzYtpb5Q iutvuqqBrmE750Jhfg8/8gfMyyc9+ZhzyDrKe6UGAUVktiBh6RaZ X-Google-Smtp-Source: AGHT+IEMNzc1ngaAhsf8EXRG4/8fv71L5Yr5nJO9GHUzHxG3qb64v7xfncg5RDpyBdNYGrOfQEYQGQ== X-Received: by 2002:a2e:b5d6:0:b0:2e1:fd4a:cc3d with SMTP id 38308e7fff4ca-2e51fd4dd13mr127914001fa.2.1715895169354; Thu, 16 May 2024 14:32:49 -0700 (PDT) Received: from localhost.localdomain ([2001:630:3c1:90:1614:6de0:61c7:40b0]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-41fccbe8fb5sm281540415e9.9.2024.05.16.14.32.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 May 2024 14:32:48 -0700 (PDT) Date: Thu, 16 May 2024 22:32:47 +0100 From: Karim Manaouil To: Yu Zhao Cc: Luis Chamberlain , David Bueso , Michal Hocko , Dan Williams , John Hubbard , Daniel Gomez , linux-mm , lsf-pc@lists.linux-foundation.org, Karim Manaouil Subject: Re: [LSFMM] automating measuring memory fragmentation Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 86854160005 X-Stat-Signature: 76qbi317poyo1mw41n44tiain3tczxru X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1715895171-544280 X-HE-Meta: U2FsdGVkX1/kHQXATn99ni6K1b6jBJGzO+X8YMPIm4tsxi6VxwQotHrATsd3sMg6++9pzhtJPa3r56ZE1LnC8hwtcMY/tBg4jZy44zBLmi+U0XZBXnZ/EYynE9UoQgffqxKpkQDeR9vBhsqbDkLYZFKw8MnWCXxZgHD7/UfF4hE+YaniU2DXmmoL2b9+qSEF3ppguPIPRNdhW2ClypYIFU7rjaW1leWbfmnQonKvfLx0/CJVpUHxdMcSzMNyab1dh7wlbQ0ZElsYXfAADfbr8HRfRiKH0tkX0ehEyhJthbwcUw964Vzh4z/MwAAN2eccZnGOyA3tuF5NGP/rFqtt8pQfY1PSpjlhXMTLK+BX4l1sKxElZcDErwK70IvEVG9UNdy1FsADfy2jNtR8qWVaEJ5IBoWO1l7SbgazhE3oOLXHePy5wgG0HLp8u3WXyJ83hnvD2AAC4BG1a+wszWw+p3bjVW2T/p0mKP9Wi1XVetG/PPklnw9awMMMU00JCANxIJ9jaQTHEBHgCkDluoK30k2i3ZIOaPvxyYr3At30VKAWHgojmY2SnsuOBCgI8bsRL1ZMCpKaLfuujBpfo0zP67AeG7huuoJnMVJilnpR0rCKGnx2gGK+fHH3lmqTfP2JoQZaPXXkg+Gy9nr0JE502vtYSMGzFkfHrhaRMxuDB6kUQsTRPrSPVBTN/01l9YQtIB21El+dn2bk/oKHQIl8Uu+U2SUZ9uXaiBhJUZeH1QMz4dT+RZqP8IgTq7AH5vVOjNeJ7pNh9QsThyBX5HJf4FpUN16d45RgFm5RQRMFx5rldxMUfmSpAYCtEhsuvOcaCFvbJRpY0iBf5IoH7im9iGfv19m4Ns59JgjXhOvtEn03nG3TWPNV+m7ZWqtLMT+1GtvtKdHlerVBRSqKhbuWmQS4yG5DqlzgEDOR5Pp41OURhIOepfo8F/D15aWFwDvwcdPTIylEO9NzRxbIF+Q IfMOIVgQ vrJIhPqqOdlP1QUVmkyoodH9erf3N4W95Y4K/LpggXXBM2Lu7imoJF8ffQA1IpSdOFqOC6ilB3EOGExU3JTHr814fNx+bf5d3QRK6SV1Sp5Jg9isiPslgNcSYnVBZXwmBl2X9DeSa7e5jJlPSnQA0wxP3bT8kAVKvE5hbh4uMezDdWo+N2YtVITIijbPO8OJL0mtTGYRbSeo/oZefPxtuuxQ1p4t7x9aTpPqEM+N/3fJX3NXtJZg0xDXkwE1ZS/U6RN5cgSUDerHNvuQ9O7oD5dvZ/dmdfyOkY+ft5DElDB3OhtV14tx6C99NbB2b6+xFLipKqZLfvoxEBBWp2nq+4UrFuX1g+okzgU4wZfG3eRd1dEoQ22Y5kre5ekSt49XpJD4lcMoffLUfV0xdyCJLKpKp4Lri87+xgGPw0sEuoG+ze5A5/MpLBpFJseq6maspQHeTaY/sN9A2ko0bKRyO2YZVcrWAoYiJ7ss3OXr52X/bDIb3b0yMa//faQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.008958, 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 Thu, May 16, 2024 at 02:05:24PM -0600, Yu Zhao wrote: > For example, if we have two systems, one has lower fragmentation for > some orders but higher fragmentation for the rest, and the other is > the opposite. How would we be able to use a single measure to describe > this? IOW, I don't think a single measurement can describe all orders > in a comparable way, which would be the weakest requirement we would > have to impose. > As I (badly) explained earlier, a single value can't do that because > different orders are not on the same footing (or so to speak), unless > we are only interested in one non-zero order. So we would need > fragmentation_index[NR_non_zero_orders]. > No, for example, A can allocate 4 order-1 but 0 order-2, and B can > allocate 2 order-1 *or* 1 order-2, which one would you say is better > or worse? This, IMO, depends on which order you are trying to > allocate. Does it make sense? But higher order pages can always be broken down into lower order pages. However, the inverse is not always gauranteed (they may not be buddies, or compaction/reclaim isn't helpful). Obviously, I would rather have one order-4 page than two order-3 pages. You can always satisfy an allocation for an order n if a page with an order higher than n is available. One way to measure fragmentation is to compare how far we are from some perfect value. The perfect value represents the case when all the free memory is available as blocks of pageblock_order or MAX_PAGE_ORDER. I can do this as a one shot calculation, for example with static void estimate_numa_fragmentation(void) { pg_data_t *pgdat; struct zone *z; unsigned long fragscore; unsigned long bestscore; unsigned long nr_free; int order; for_each_online_pgdat(pgdat) { nr_free = fragscore = 0; z = pgdat->node_zones; while (z < (pgdat->node_zones + pgdat->nr_zones)) { if (!populated_zone(z)) { z++; continue; } spin_lock_irq(&z->lock); for (order = 0; order < NR_PAGE_ORDERS; order++) { nr_free += z->free_area[order].nr_free << order; fragscore += z->free_area[order].nr_free << (order * 2); } spin_unlock_irq(&z->lock); z++; cond_resched(); } bestscore = nr_free << MAX_PAGE_ORDER; fragscore = ((bestscore - fragscore) * 100) / bestscore; pr_info("fragscore on node %d: %lu\n", pgdat->node_id, fragscore); } } But there must be a way to streamline the calculation and update the value with low overhead over time. Cheers Karim PhD Student Edinburgh University