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 B5D49C46CD2 for ; Sat, 27 Jan 2024 08:06:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F0DE6B0078; Sat, 27 Jan 2024 03:06:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 17AC36B007B; Sat, 27 Jan 2024 03:06:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 019EC6B007E; Sat, 27 Jan 2024 03:06:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E1A0C6B0078 for ; Sat, 27 Jan 2024 03:06:53 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 891D3C0221 for ; Sat, 27 Jan 2024 08:06:53 +0000 (UTC) X-FDA: 81724359906.11.3464155 Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf08.hostedemail.com (Postfix) with ESMTP id CFD2F16000D for ; Sat, 27 Jan 2024 08:06:51 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Rb4C3VQ6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=ioworker0@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706342811; a=rsa-sha256; cv=none; b=GRVYiRdKNUODRoGS2Oc9Jn9t59WeoZpVJrsTFmnnnQvZgnkIPRC23dou3WFzO/EjcyJxp9 tkYERgJmXB4NpkHDcpOuBeHnzVaER/jWv+dFE1cAJwhrp0wDZPibwi9/Ipwofh1PQnwDV0 aYXDyvdi72K4f7HbxSG+TYjixiV6mOc= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Rb4C3VQ6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=ioworker0@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706342811; 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=xJZ2TcuXVx0HQfLG7ro+wBJ7/ZMJJMbceBk/8o2W1nA=; b=suNg6sqWtnXZPVjYE7DfruGzoTbS0tqvgF1uemw8g0mPsAJye5TuTofiHHSy75SQ2phEb/ 74yNIQznJrE1RQCP/+QkmFYLNbuEkyMEcFOLIgLQtOeO2F03U/ioiHuHbYOZGneUV6WRGw YfU226UdHWLfEnyOkG7xCZd3uoPfOvg= Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-5ff7dc53ce0so9157577b3.1 for ; Sat, 27 Jan 2024 00:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706342811; x=1706947611; 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=xJZ2TcuXVx0HQfLG7ro+wBJ7/ZMJJMbceBk/8o2W1nA=; b=Rb4C3VQ6uMbymWi5VjOBNZ5FCzLiM2r9Qm1phYKxUdeWzpvnWGyOkgbSP91OCJ3amN Bb2cTXE2clSxwo19/8ATQ5C0aCTzZVg4ir2GuuSxdf4dRr/13MM6Hg1qWqeg7noCURfS /tKQrf1Hp91DzakOKcE4DQZVvbgNGml4xoyGE/yLbvHYahOmgXplCnMtoh8fy9q6PUl1 eUbxnx8h1wSJiu0u+XdToj5MjNWccg+Y0vDT3rDOGiunVdfOohnUg9a1/iJlJV30KZmv jX1opFMyWyheks/L0p5RfQbCyRJvpqSTPKYf6SKbTGU09fPeeMkeHKypRhBF6tyjakJ1 6uTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706342811; x=1706947611; 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=xJZ2TcuXVx0HQfLG7ro+wBJ7/ZMJJMbceBk/8o2W1nA=; b=DN+4+QEaFy9J46RCw1Q/2HuSExA55iyewKk9Gmcgd6GntV3nf652IfxFkFeX+9cLkb +hOEUkJYfIVlPrgsilsn+sb4xilzYo7M8S7yWjOLb7JZ1Ohxx7ZWlJ0fTy4bvOtjdBTf 7tXREUDxFxD8ZChD52muRYrz3uCOWGEV2fl26gywz2YkBLNg5pFGXSerHxrULQajjB8m qCX1Vsii8MKtSHgAJ+Xtdinl/CXJ4N+krt0DfrY7MObyqJNRNxgzoQWQcwvn8VhKZg5d +tRp0FlyJFljwSESe6/pc5UfePrASDjogcfBLNAmAoJs+3eQpj92rFKg3vNoAPViTny/ SpsA== X-Gm-Message-State: AOJu0YywRi97nozSS0WnijizYrEz1GMOtwO9wYWC7gi2PbvA/nH7FDeJ yGXbvQmxQltcOymNBfkl5asPPUjUdjLco0s8uR6E9VSaO4YWnvjGe60wP5qs5+BZlVdNY4tqfVC zky9qocTFP5nfo6YDBL6aiHso+FI= X-Google-Smtp-Source: AGHT+IE445rhgCPgk3Ky3+sDSrPR8Aq6mhKsin3MfmkfiDsbyxUYk8hj4tB88oSHwDfLTHQaYrrNcfHA626LSQFPk20= X-Received: by 2002:a81:b716:0:b0:602:b725:c762 with SMTP id v22-20020a81b716000000b00602b725c762mr797845ywh.56.1706342810937; Sat, 27 Jan 2024 00:06:50 -0800 (PST) MIME-Version: 1.0 References: <20240118120347.61817-1-ioworker0@gmail.com> In-Reply-To: From: Lance Yang Date: Sat, 27 Jan 2024 16:06:39 +0800 Message-ID: Subject: Re: [PATCH v2 1/1] mm/madvise: add MADV_F_COLLAPSE_LIGHT to process_madvise() To: "Zach O'Keefe" Cc: Michal Hocko , akpm@linux-foundation.org, david@redhat.com, songmuchun@bytedance.com, shy828301@gmail.com, peterx@redhat.com, mknyszek@google.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CFD2F16000D X-Stat-Signature: p765syew637hqghrjieb1kz7x9o9u9rj X-HE-Tag: 1706342811-535023 X-HE-Meta: U2FsdGVkX1+HluWmwrnLA1pLtoLudDKeO5CCn6xTo3aSG8N7gyC7jGsEwkqlujD850RWimgrThk5C0IfJocdJ7KJ7IBvr3/iTVlV7CG1Xk1GlY8CCLr3TiTiTQajSX0tliT6t90oGC9T9GRR5kYzH0pCKLrM1bQ+JyTqGDsYO0Sx8M1wwMgwJI0wBS9vfmSxzqlYd+bLLThXydJulSv+Vj94u2wDiaHGe2oBGUpJceqIzxpX3Hq1Fl981ocs+ypOdPxYFdIwVB9lDfFLFSmPa3AzZY0Fps289ZIRlFZ4z/UGp3pJgcOnasDVdJ3KHlAv9WbEzlTjWU5okAiHhdfYyBObyRR4vl3gqf71Tu7J1mD0IjRdAwgxWZvS77NoOKrgl4CC1qVNOjQdH68gu2LxYCtvUDc0oysYYW4YfPWECbxx0msPxX8NNMoFIIdSQKaJzJn2LK/18zafAJM972RFogjOPXp3e9S8EsRSWDjkIflBXBKBCpo0fP9DlMzwD7RrSlAR0F+60+soedxv2IHxC2Pb/T1EOkWcqhhRJ4LAlRKJTvtIig/Vpq1yxj8ksxFQL2JPS5SxEpw/PIAj5H+7+FQMBOo94JsIoUdLuTcUZvVGWqezDVmMxQIVkD/Pi4aB5wrg46habBIaxrEDZDHFBJu3Ixc1+/b62T7uKabJHisb9fsJF4fcwjEr9BteaS7VXOCFOpHvMYEHkdxPFXbjrYKYqPTmVwJrv2s5lI88pU8Ofhc1A9HmAX86OMiG9zvLuJf17XmOh/5atY3Zj64673NlfGMLcmV9HRlqiMKJWTZ8n+LIdu5lD1Jki9BGsyn48jB4x2yOnMHxiSnnvNXyr2GCJBxhTreSur+2tZSJYKcjm0RuX3ICjSw5oLqkMd2pXQg33MOKAC/wTuzQb4cWAYU46l11acvpbNqlSM/MeU2N8rP9adAJ3KbojMr6BFzi6CfGqpLB6BXCcqLxkty 8Ct8xlan Qvo55DlN9hKvXZkg0qCyVsMKCj+wf4Bk8eeITOR7TUdOssdUI453fO1KWruVuK0ydpugs38z9L8S7xy5IElzm1UiL2WlI1H6u7b3HVIBrDXDSdcG5P4uWm0dbyN7dnPU+TS4p/GrZ8y4Uw5LIzaOq5hVUhsSEo7UxlcuqTkbFQDCWtlEWRthzrM/jk3Cn3pn5GARxe020JBQ1GdUW3N8n+WNJGQGA8yM1D7MEb8DvsFmv80Sa3VC/GJjSXZoQx0e1/0DE3590Q9f4CAuTQKvX7Rn/hoW1pCrYJgMgDxaYqnvKwBbUWEuXoAslItTGXnxzUEM0kYkWu0TzJJexHAidNI1+dHlnXgACV1vpgHcDHcqglgj+sh95BkESW7MZk6vhq6cVCyMIV00RT20FIhrBiatm66bzbdR0pjSR/Raguu/OvLmrqLJcd/lMpb3/Mkx8dKpwGoBSla2vSjHC2Ip0iZ3gdfkXhU7T7Xjp7Ivy0pJMEZUIhtqIopjq3E/2lD3/pLLe X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: How about MADV_F_COLLAPSE_NODEFRAG? On Sat, Jan 27, 2024 at 7:27=E2=80=AFAM Zach O'Keefe w= rote: > > On Mon, Jan 22, 2024 at 6:35=E2=80=AFAM Lance Yang = wrote: > > > > Hey Zach, > > > > What do you think about the semantic? > > Hey Lance, > > Sorry for the late reply. > > I can see both sides of the argument; though I would argue that > "non-blocking" is equally as vague in this context. E.g. we'll "block" on > acquiring a number of different locks along the collapse path. > > If you really want to talk about not entering direct reclaim / > compaction, then keeping with the sys/kernel/vm/thp notion of "defrag" > would be better, IMO. I don't feel that strongly about it though. > > But I see you've provided some more use cases in another mail, so let > me pick up my thoughts over there. > > Best, > Zach > > > > > Thanks, > > Lance > > > > On Mon, Jan 22, 2024 at 10:14=E2=80=AFPM Lance Yang wrote: > > > > > > On Mon, Jan 22, 2024 at 9:50=E2=80=AFPM Michal Hocko wrote: > > > > > > > > On Sat 20-01-24 10:09:32, Lance Yang wrote: > > > > [...] > > > > > Hey Michal, > > > > > > > > > > Thanks for your suggestion! > > > > > > > > > > It seems that the implementation should try but not too hard alig= ns well > > > > > with my desired behavior. > > > > > > > > The problem I have with this semantic is that it is really hard to > > > > define and then stick with. Our implementation might change over ti= me > > > > and what somebody considers good ATM might turn int "trying harder = than > > > > I wanted" later on. > > > > > > > > > Non-blocking in general is also a great idea. > > > > > Perhaps in the future, we can add a MADV_F_COLLAPSE_NOBLOCK > > > > > flag for scenarios where latency is extremely critical. > > > > > > > > Non blocking semantic is much easier to define and maintain. The ac= tual > > > > allocation/compaction implementation might change as well over time= but > > > > the userspace at least knows that the request will not block waitin= g for > > > > any required resources. > > > > > > I appreciate your insights! > > > > > > It makes sense that a non-blocking semantic is easier to define and m= aintain, > > > providing userspace with the certainty that requests won=E2=80=99t be= blocked. > > > > > > Thanks, > > > Lance > > > > > > > > > > > -- > > > > Michal Hocko > > > > SUSE Labs