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 1CD58C25B74 for ; Thu, 16 May 2024 21:37:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74F406B0083; Thu, 16 May 2024 17:37:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FF6A6B0088; Thu, 16 May 2024 17:37:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C7586B0089; Thu, 16 May 2024 17:37:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3F0DB6B0083 for ; Thu, 16 May 2024 17:37:38 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id AA2A180F28 for ; Thu, 16 May 2024 21:37:37 +0000 (UTC) X-FDA: 82125570954.23.6DE1B4B Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by imf07.hostedemail.com (Postfix) with ESMTP id C9B7F4001A for ; Thu, 16 May 2024 21:37:35 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Ccz57tZ8; spf=pass (imf07.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715895455; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DpbGlukDdbDtHalFDwJkU6Ap7inngSAj7eprhE+7hYg=; b=QEot1kqStLT7d5TErogECq27KOdKk9ffwz/rg3RUlt5KKDP/7BT/9+ocvtJOIwf9HbnPki S48+OYZfNZ/3xE2xLPWaxUp9M7Zl2eufe/iFDU2+szcgYu9XGBTYhZXOru5LTRlWpg5x+y jRd4FaiunQMvMPQk+qfDV7SawhbvGj4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Ccz57tZ8; spf=pass (imf07.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.53 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715895455; a=rsa-sha256; cv=none; b=YMPFIj+dhcO8Qt2iEy8mzFt9R0bdF7bMEO7vmjB1DVhkuhd84aaAoD4XIEaNseI1J42C9e SpP9+teZSOyDSRZV4hECHVCWCF68835gAZ2BtMAU1nomDPCMDYnSA7oL9jBNkW/BJRKyPV 1U4691q/378P3WzN9ZvhG7pUWdGCRaY= Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-420107286ecso28275e9.0 for ; Thu, 16 May 2024 14:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1715895454; x=1716500254; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DpbGlukDdbDtHalFDwJkU6Ap7inngSAj7eprhE+7hYg=; b=Ccz57tZ8nj7HwZcwEDhajUoXepyyTAq3zO9t9qjNJIR9EWhTif+2qyDx9RpsEucCTE 7F5o4FXbW5oI0JqJQ9t1yyN0SBQK3zkB1RLfqwSsIgxtDMPoO0qUjLeiynWrzCxAFmSF Wrd8vO6gm86d0X1D9NoitoES1K02bW6R+1bCUtaajtclekoCItGU4EVZPIQn9QbaBzXR Ylw1+hg2IITeyo1W99Iy9h0a0VhiSYsxeriyUN6wxPnzh0AIQExqQGtqBgYElK3YH5BL XDa0vl0bdv/DmgnfBW1pFINbhmI8X2qgvfzNXtOJZSmLstJwTQKgLW4iLpWg2TYTU9CG ap3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715895454; x=1716500254; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DpbGlukDdbDtHalFDwJkU6Ap7inngSAj7eprhE+7hYg=; b=lmrNONjwojZs9OBv2W/kh7DijGRMu5nLuKB6E6UmToCMiSA8T8KhDPjTXzJqUu2w9E WHxWP3CDik7pUxrgc1P1kRS73c2xIJANMQiFh9pXvL23uiQROLf/p1hxYyPeKRo2+LaW uYQkleyjO9hY8B/U/PirhkOpCQw6lDMhwxPlYIYO2apOJaXnI5WAHO0QTni9mo9YhphU fE/fcJLR60wj6dPs8iRRRgA+1R42X7ScCQxjytj4Qh3gOYx0Iv6jGNuW8IKvSfcBxQw8 ZWWgksecOYL4kXT7IQGLcBVQRE77XlXJjI9wHlQHYXz7MBJiVE+QOpdwi9LWGL7kexSu cdsQ== X-Forwarded-Encrypted: i=1; AJvYcCU6Xp2s95CacRAVvhaZcwfTWurZ6Cf8cbvLRj1T2Etw22yyTnSSTCkKF7iyDf8qrjH6KQDET6BfjPGkl4n2ohOY3W0= X-Gm-Message-State: AOJu0YwbgGUTcXir9aGP/3afmJuMSz3eK/xuPrZBhEooL6TOQQWxVc15 zE1bFItcPy/wdCkkN6OpViG4K1CCdMVtuWAntdxCvGu+Z7fsiHq4Iq24ziVsHMUf+wYPxpP5iC3 ++E+GCexqXkn7JZVBRziDe0KS5MYho86nHRoP X-Google-Smtp-Source: AGHT+IGWMeTA/YUJ6K6ZsurbiZf7VcV7fX5A3GgJ8dMbm0h0q1+W5/ez/W3Ul9iBLBjtpKp9o2ZTM+ryWKsV8VXMEf0= X-Received: by 2002:a05:600c:34c9:b0:41b:e55c:8dca with SMTP id 5b1f17b1804b1-42030dff23emr143135e9.7.1715895454019; Thu, 16 May 2024 14:37:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yu Zhao Date: Thu, 16 May 2024 15:36:57 -0600 Message-ID: Subject: Re: [LSFMM] automating measuring memory fragmentation To: Karim Manaouil Cc: Luis Chamberlain , David Bueso , Michal Hocko , Dan Williams , John Hubbard , Daniel Gomez , linux-mm , lsf-pc@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C9B7F4001A X-Stat-Signature: s6ku1s4ytjyykirawje399of7bpiwcd4 X-Rspam-User: X-HE-Tag: 1715895455-626529 X-HE-Meta: U2FsdGVkX1/oey6rgOd/UYX2nKxxPwVeEaRk62IBpml19eDtzKpgKyb8PrcB/7rRmSPIl7nf8bd25va165j62ZPJqqe66SUyl42BQhiobSo4GwwzGsfSuWwjlTeqPP5jc/H0+2qupxUK2W+lVU0RQyouzQJqZNIArHR9vroBoPvJfLcG2LeaaiiKXWqPCXaESAJMYZWb9oOP4Fla61IjkzGXkU3/mjIDg8tnVDxlqe+kgXYPs8dak2j1R8T42S5C3Xwz8a+qMjIIRVFOFlq0YLoFp5JmWrk9enBUe0BgVKdbXIxbYyYjjLwJsq+puXm4mHidHZfS/nvgIxggx2Gwlcd3JE82VOi2xnRsvPqJKg9QetGYU6yxMLhkCtnE4nfDQPPKXx7tvfYfZggfUVddY6AgrTKMLXyKakirkO6A9dquPGX1iBw9CkhXfI0sc+f3p1bpwmYsSD+5IAPjav/7RumxanPlCi/sjH6ET9eLunPeIjh6v3TszoGXmknHkUYHPnfCXc1UK62h5853gPIW0/6yOSKE0h/hrznmatWd1xsQTE79B9D9DomUQSVoRz8WnqTOTJnlI7wHSgII3A1SPdrCGpxM/88ANvhHkK6sh6nHOgY7n4WlNkpUiyESgMwJ2b3de58JJOmgcOmCIfd/LKco+kuVg7ZbKoN9Qi9KjcWVHNd5Oh1g1qNM3k++uxeClZji6XowkshjZjOJEgcJBR48eJEbnWCJb3HEz4J5A422tFMZMOoqmSYrJcsRm0TwKgYaLMJJuLwIjAKTmcse7k3YCqwGLlHLpnqe/vEMSoUCozMfjhbcWDJ3rzQkXwGyJ7CSe4cyBk3QwVsCg/NRVEAMYfFg29kiw8XMoAUAgxCmgTHF+1L3E7gwdEkjNJEI7pUTJlk029tkehLNmVvN/+ftMdej0OxC8xDTnSFiB4jrTqjJQp1mh8CoNRvpi5CYxv+iuCGD8PhUEf0STWm xAKG+Nq2 IL4wWxbLZIifPqlnWDOdl4A+PU8cHKm88jizMDq4Lzg1qy7H30c5b94/oj2VbV+6eVCwiPvlY/nF4kd1Z1uFvOFgH50NhXmPKG5keOF/hh8be82hSv1Z/TlEqX3FuISLPZTdicqmnaX+K9o14+u0uyQS8sK67nOKkF/5SIfC0rGWoQ8F1oU6zky2Aozr7NcLxPkJ6uliKjQSO54wRkFwhO5kmubTZxRXxaG4vhc7inhrBVOQKrRPDKbAfInwb/BPT4sVevah0uUCDj42232C/QJrztgNvo88VWWKNByIYSkBGY6R+CiwnnSEluN30GzqSye3a X-Bogosity: Ham, tests=bogofilter, spamicity=0.043475, 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 3:32=E2=80=AFPM Karim Manaouil wrote: > > 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). Please read my example again, carefully. > 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 =3D fragscore =3D 0; > z =3D pgdat->node_zones; > while (z < (pgdat->node_zones + pgdat->nr_zones)) { > if (!populated_zone(z)) { > z++; > continue; > } > spin_lock_irq(&z->lock); > for (order =3D 0; order < NR_PAGE_ORDERS; order++= ) { > nr_free +=3D z->free_area[order].nr_free = << order; > fragscore +=3D z->free_area[order].nr_fre= e << (order * 2); > } > spin_unlock_irq(&z->lock); > z++; > cond_resched(); > } > bestscore =3D nr_free << MAX_PAGE_ORDER; > fragscore =3D ((bestscore - fragscore) * 100) / bestscore= ; > pr_info("fragscore on node %d: %lu\n", pgdat->node_id, fr= agscore); > } > } > > But there must be a way to streamline the calculation and update the valu= e > with low overhead over time. > > Cheers > Karim > PhD Student > Edinburgh University