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 97CA9CD1297 for ; Thu, 11 Apr 2024 05:01:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB21A6B007B; Thu, 11 Apr 2024 01:01:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D63EB6B0082; Thu, 11 Apr 2024 01:01:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C29EE6B0083; Thu, 11 Apr 2024 01:01:37 -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 9EFC96B007B for ; Thu, 11 Apr 2024 01:01:37 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 68FC2A0A32 for ; Thu, 11 Apr 2024 05:01:37 +0000 (UTC) X-FDA: 81996053034.02.957052C Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by imf17.hostedemail.com (Postfix) with ESMTP id 93F954000E for ; Thu, 11 Apr 2024 05:01:35 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aCo4iZYA; spf=pass (imf17.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712811695; a=rsa-sha256; cv=none; b=U2yje/UDFU1jR3lB4LSyuuE6QdooOdA/+jt1/AAFKkS6s+ItZBrRXE1IbDz32oAiVmTTEH QLrh9Ns/Clx+yWHKZi4AP6y7gWimkYeng2jasklSZVwTcUrr/TrMFzrySsDeSS0RYoowBn JMEwUVF5/K0z+/M6j/NN4CDuTW5U7TQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=aCo4iZYA; spf=pass (imf17.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.52 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712811695; 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=a5zPyMdwgo+w+yECqX3qxlIk+FaH/Kv/rlRwtfxjp+4=; b=FSG/o2Tpr5ihGzl1nhrZyOe8VEgweTSPbgi4Ngz0SLDNgCtEFQpsaNUKM/CFI0NfqEKMQI G0KvcNy6PmRiOm9izKjdiXHzSPDaE+I6mXP+I72BpN4zS7oeXrvZRNutAc9iaoQY1HuC42 QLn9Qu/KhJS9dNJo3E7BVhUFvhaJiHE= Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-56e6f4ee104so3975818a12.2 for ; Wed, 10 Apr 2024 22:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712811694; x=1713416494; 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=a5zPyMdwgo+w+yECqX3qxlIk+FaH/Kv/rlRwtfxjp+4=; b=aCo4iZYA8vZixpmt0MYrPyEDk9N/vxQzAF0c5V/zEYc7kYhZHuuAo4bXRE+3OuV8Y6 g46t4pGVejdmpE+IV48AiRI/8wflcE/yUsRnnPyeSEXUrjKVj/GUVB0s+6GhvYe0XfVp VGH6hTiIub9ZhNyexnaaEFrxyaJeOnFAKC+F5dradaH2cDkrq5iXKgpChyqDWqnxusG+ iXwheiAaqBQfKZa0gZpEgx9cn/Itdh9Nz5Jr1D0n6UkPi8px9ddWG3gq+cdPSZISEd6W UShM+he74CaMAc+dKJ9myp+UozhoNkTLLZDNAtvUsu70oQ6zqR6pWJvgGhoBdz2ZDV3o c4Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712811694; x=1713416494; 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=a5zPyMdwgo+w+yECqX3qxlIk+FaH/Kv/rlRwtfxjp+4=; b=SxJtCqDKYnlz/WqYfM6q7F9+yP8KeLWBf9swcACt5mgIUO4XV2TeJGw9JWBIc5WZp6 isLPSubnbkrTWRTwHp7v71eOKm9reC3rO8gHCNSNaa+cEDFR+CwKv7kkPuIkCUtO1k4t Byqgmo6pqHMVhevzww6ZBbSorrLyNe+tATQfOnQePrvvrWviIl17G0plDLaYU3LVI7/7 5dlwvGOW4u4Ja4C559VMen4C/AD3UEOcSBwQ4V5Cez7QqPkXHWfj/39sWzLMmQzG3JT6 6Q8gCCYkUw3/4PJ8smptm/wQPJ7SZ2abuMiYxsAkaaF0I2nFJdPfc3pMvSqpNua4TK78 enLA== X-Forwarded-Encrypted: i=1; AJvYcCVOWtUZtS95ufe0d13Cr4HQImW7q7Gvbpf6KNPBNO8I5/oFapb3Bfgc/9ho1qVf0B9o0HNCzSg7CdKM7P3GNXR1ksk= X-Gm-Message-State: AOJu0Yz0JbH9XDdnvgkE74sg3TgCTeIwNkfnDJ+8DElIoH39EloTG+x/ VRJghh4LlQs4LCpgk1bYd261SPtUoY0E/j0U410dXSjHspvipmjCWZ5KAIS5zeajeMjDe7HSVLN 3HmCkvO6VpGbJku9H6oBu43nlfAM= X-Google-Smtp-Source: AGHT+IH8mM3PhWf6bzKNeaYLnokUe4aOJ7koL6q+Vp/F62299NTENTD3A6OoFV7kJcs5NAC5cWgh38xqL8gEdRiEApU= X-Received: by 2002:a50:9e0f:0:b0:56d:f47c:5308 with SMTP id z15-20020a509e0f000000b0056df47c5308mr2416750ede.34.1712811693708; Wed, 10 Apr 2024 22:01:33 -0700 (PDT) MIME-Version: 1.0 References: <20240408042437.10951-1-ioworker0@gmail.com> <20240410145033.5cdb8a41f3a6894a62191f42@linux-foundation.org> In-Reply-To: <20240410145033.5cdb8a41f3a6894a62191f42@linux-foundation.org> From: Lance Yang Date: Thu, 11 Apr 2024 13:01:22 +0800 Message-ID: Subject: Re: [PATCH v5 0/2] mm/madvise: enhance lazyfreeing with mTHP in madvise_free To: Andrew Morton Cc: ryan.roberts@arm.com, david@redhat.com, 21cnbao@gmail.com, mhocko@suse.com, fengwei.yin@intel.com, zokeefe@google.com, shy828301@gmail.com, xiehuan09@gmail.com, wangkefeng.wang@huawei.com, songmuchun@bytedance.com, peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 93F954000E X-Stat-Signature: n6hpmkur6h5mzbjunep8nc38ihutywrp X-Rspam-User: X-HE-Tag: 1712811695-700604 X-HE-Meta: U2FsdGVkX1/Vi16kY6DDmsXUMeQoT7wtDc+p5+3wuLU3zr0UdBlugs64ahVI0BN7gBM06Ef6fT2VLZcyAyR0W5QoqywvBtvhv9VnJMTvTUhBUdFwh9L/QngkWhTudsHXn0jdbYq1qHazVtILhyEtfG0o/yPT0MosnvINO1AREVMEjOARUxdEjjQXjsbmm1MUkP3pfbJYmdeawTqAat4Jb2Hy+QmS9OpBDbTITE2Uk8NRLY0Rl8+d3yBPZsf6gvfgEiFZQtMAwIwL6U2wLWFd57tf+p8/nDw5cLEdgzOdwHD8KBQTf/L2q5ReEOcnhzBW+CHvKffHxhfDOsUSCUf8Caa/a3055EHS8nKsZWqfBMmnkAr1kGZzVWOOjEJoq0fxR7Rw4/Rael5XursP7ET/REHZWMX2CriEYzVMwBkYVFO+0oAVxJPXtLqQyGQPws7JBcNnxk83eOU2O5M9jURHt9ISrBr9J4845JNXnX+hs3Jri5zbJ9aAc5y71YSAJNkSU4ffMjFH8SCZkz8WUKUFmkPxhoqpqorJcLM4zS1C2dXNgZY2GqxStoXII7Oc5yoM4P8Ko02j6gU/TfIWWS/i5545HkDubSWq6hdQSuP9fulfTsMwh3J526Dkt3EwDcC4sL8vXLd/VZexYdUbs5dqF8qYpTwx89VJeKylmYGHhM4obLlrjh3CTaY6z7LzaiZVb9feg3XPXjj2RlFPZa/M6StsyDLZPjUa0TZdd9sN+VoDTO5/HN2pehShmzoxDArYv79jaIwRTX803j8t5Rw1goVW/hzlxv7hmSy4p5IOkpT4m8oL2UWvz7p5gh5hFvamFDgzewkpywHzTmIlcP6tG3WQu837muGcIKGjcCk2XDKMT2/3ljZroOFWEZ1dGSHHfmRWqvzwP9kwdQUYM17HyqURDbSHnh+pyBQ6qlNy34hd75ncIXOsMIOf3gkvtkPlr9+1zSuWhaD09oVVE67 6W+spNRW RNKFN5+ggTx4Ouh4tn5TNEYZgjshFTkf9ob9OQr7+qlpiUBhvr6FG/EvEDn0VDnYTY16tmUQtxkTN53uGFXIISOHJuKMw/rqwkqwMKag0cwOP/x5qtegG7vcrFq/pqfN/w52fgbi2QxUEp/wIpX8OTS9Dv8xyBFdjNPTpzIr6GEQLGxxYfvQf/MDatSfMnRX3At/ZnBG+bjsfjzLl+agj+F50A4WSAIhIOOfT+0hchEs9K/bcWY0n3v5NrMkRvmGSRDiiLQ1H9JRmtBVeYaN4Pj6IBXeGygMTRB3yCEx2/sLMhK0XN5uOxRTSVASr0yqiVFTIoirQHa1K14YiGkPiu7FvrIxd/zCzRTlCKR3WA/YvZzkTu+5cOYu5Dkxy5tycQlUlRQai6dJAQHPFqWXUB26iEC8X9GfFkhPjQ2eKhDjGKlnOLLS+7q8wQj7gA9rm8gWIQWJeAxOJYoTCmQpBvzTB68A9ZrPUDwe2ecnx/xO74mY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000628, 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, Apr 11, 2024 at 5:50=E2=80=AFAM Andrew Morton wrote: > > On Mon, 8 Apr 2024 12:24:35 +0800 Lance Yang wrote= : > > > Hi All, > > > > This patchset adds support for lazyfreeing multi-size THP (mTHP) withou= t > > needing to first split the large folio via split_folio(). However, we > > still need to split a large folio that is not fully mapped within the > > target range. > > > > If a large folio is locked or shared, or if we fail to split it, we jus= t > > leave it in place and advance to the next PTE in the range. But note th= at > > the behavior is changed; previously, any failure of this sort would cau= se > > the entire operation to give up. As large folios become more common, > > sticking to the old way could result in wasted opportunities. > > > > Performance Testing > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > On an Intel I5 CPU, lazyfreeing a 1GiB VMA backed by PTE-mapped folios = of > > the same size results in the following runtimes for madvise(MADV_FREE) > > in seconds (shorter is better): > > > > Folio Size | Old | New | Change > > ------------------------------------------ > > 4KiB | 0.590251 | 0.590259 | 0% > > 16KiB | 2.990447 | 0.185655 | -94% > > 32KiB | 2.547831 | 0.104870 | -95% > > 64KiB | 2.457796 | 0.052812 | -97% > > 128KiB | 2.281034 | 0.032777 | -99% > > 256KiB | 2.230387 | 0.017496 | -99% > > 512KiB | 2.189106 | 0.010781 | -99% > > 1024KiB | 2.183949 | 0.007753 | -99% > > 2048KiB | 0.002799 | 0.002804 | 0% > > That looks nice but punting work to another thread can slightly > increase overall system load and can mess up utilization accounting by > attributing work to threads which didn't initiate that work. > > And there's a corner-case risk where the thread running madvise() has > realtime policy (SCHED_RR/SCHED_FIFO) on a single-CPU system, > preventing any other threads from executing, resulting in indefinitely > deferred freeing resulting in memory squeezes or even OOM conditions. > > It would be good if the changelog(s) were to show some consideration of > such matters and some demonstration that the benefits exceed the risks > and costs. > Hey Andrew, Thanks for bringing up these concerns! I completely agree that we need to consider such masters and include them into the changelog(s). Additionally, I'll do my best to show that the benefits exceed the risks and costs, and then update the changelog(s) accordingly. Thanks again for your time! Lance