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 9AD31C47DA9 for ; Fri, 26 Jan 2024 23:27:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F41716B0088; Fri, 26 Jan 2024 18:27:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF1A16B008A; Fri, 26 Jan 2024 18:27:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D92106B0092; Fri, 26 Jan 2024 18:27:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C98B86B0088 for ; Fri, 26 Jan 2024 18:27:13 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A6955A1DAF for ; Fri, 26 Jan 2024 23:27:13 +0000 (UTC) X-FDA: 81723050346.27.BB03DDE Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf27.hostedemail.com (Postfix) with ESMTP id DE7E040005 for ; Fri, 26 Jan 2024 23:27:11 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RaBL1Qk5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706311632; 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=7EM22NdD/R1gavpoQkCkmyle3YA/s2Xcz1M+2yhhH/I=; b=vQi+Vgztez57pHbPRdVSuxPYaGtDdBFhzD+r7f34h92Eh/eJzQlc2EclHP9cz1iP5XoVY2 SoT7ITKucHKpGnyAoOXQVdzJR2xFlMSXpW3J+v7bCNNRjtIDbrVtWObA0/k/8QjJdeP5gm 3omgznX5Y9BKuU7hnIHGkNI1WmbwX30= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RaBL1Qk5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706311632; a=rsa-sha256; cv=none; b=S0bcpmvKrVDQORFP4dCb+CWJWoWVZPHq5C5cyfyDoEiqg3by58v7M0O1ZHLGztmDWPxjOA DlfLMJ/6QtRVURrbZn3XYzLY8KNItUzjdbuoLX/ZsK3bOG04GFvh4JFwPh1lyno1qhr0GB N9LJaO2XZvrnd/P+JxA90YmHbXXev0o= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-55c89dbef80so1259a12.1 for ; Fri, 26 Jan 2024 15:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706311630; x=1706916430; 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=7EM22NdD/R1gavpoQkCkmyle3YA/s2Xcz1M+2yhhH/I=; b=RaBL1Qk5gyCsWH40cBkGENmU5qcCZ2LWeXszjROlxGZ0oyb2RJUac8DTVt8E4p7mCX Sk+4HdeKaFk6LYINeDNbzwlWhw56EGJ9MnYxWbDOV9YhWtSym/gPydcqGx+wlJRq+xoZ ZHQ60ZedhIYzSa/rkatik2gFZi5IsRM1kd3DwziHSgKWwZlL5LBsrz0oKsPrurVV97vk /+lh8FdiWnYd90mSQ4PVNKGPvZqn+klYEWo13H/rIAOmxfaS+v4O9caJrnrgnvGAjBrB NflpUvE1bCcUL+RY3JqtnfDnm7vtcWhD59+3Y0m/I/TxUs7UqdGbrovOB3f8m+3i4+aE +BfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706311630; x=1706916430; 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=7EM22NdD/R1gavpoQkCkmyle3YA/s2Xcz1M+2yhhH/I=; b=tUoe/rXRFhYuh40wvCMXoYigyiSctW6/iTWzqZ48k34AAtsl3HSdwntNTILaBNhE+s hJ5Knfud2tmAsrpUfLAWbtGCfOno8CM7kdQC3vy1sCnSOgWxA4N54QW/vINPYYDn03E0 tOoL+GtzQ9ptY8Y7AWOsugKiDJsRkvd9AY4hSCY9ifDBxaeoKqZi+WecqcMJmwI27bpS qWE/aH7hiX/tkNIebhv1JTZa8c1vltAaFOLMu8nsQf7XN4JnJ4mYpmzLNwYYbi+1fdMz axQOWpBi4WDxoiK4peWKFvg8kqOjA7FqAALGfXN6EPsQCfipZ6C/k4OjUgKOrdmqw1zk N0GQ== X-Gm-Message-State: AOJu0YzewMafAyqq9LChpOSUk5/sGzrFDlDwbclKWmp/sF4CUq9EB3d8 3V1holvJ7+QZNv+OaAZE4CROFpVJaqgfyp/t3aGWFNeZNBKyjX1lPBO7Uh5P7qQX9KJAr8+vUUd kmrqbNCFqqO8A9fBkp/45Lv3srLPh/7pfRL3/ X-Google-Smtp-Source: AGHT+IEytN94Tw4OAfhLp8QPfVkL5LpSpNvojpumHJ23Z4yh5ep8lAuk/NNUIwncbmQt6kFpEx1hzb/liCn+dCwP4tA= X-Received: by 2002:a05:6402:5d86:b0:55d:4375:c39c with SMTP id if6-20020a0564025d8600b0055d4375c39cmr166144edb.0.1706311630220; Fri, 26 Jan 2024 15:27:10 -0800 (PST) MIME-Version: 1.0 References: <20240118120347.61817-1-ioworker0@gmail.com> In-Reply-To: From: "Zach O'Keefe" Date: Fri, 26 Jan 2024 15:26:32 -0800 Message-ID: Subject: Re: [PATCH v2 1/1] mm/madvise: add MADV_F_COLLAPSE_LIGHT to process_madvise() To: Lance Yang 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-Rspamd-Queue-Id: DE7E040005 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: idadm35pmwzhgwqimesg9yjgbkbd717g X-HE-Tag: 1706311631-636387 X-HE-Meta: U2FsdGVkX18msu4RRygsVACHKfIrkszYQrjubWzPOQXWaitDVznOkZ81e8TZIzlBCUExQhsTjGiHek9txhQ5CUktZ6J4YvvWdmJHqYO1ZtTC93G/XAz2A/QST4jlZg6pv1GwO8NFf895Pvgpir7SaddImJdzyxBgNTgeTlr7QVP9x+1+kxP+OTTOB/gQdvTVM/I2E67qG/W8nebMr3vsrdKikHWgwZYHesxQNENVU3PR7Qj3aHjfCGUeVMOvX8UL5/OA10sxY8tQ3wK2XzAy9J2hny/ykjIfptcWING6j/IaJ7LG5PG78oOUqGSZBfg5zTFsJxqSQevpk6nPfgl61D6AF4kSTHLv5IfjynHpdMEbgI4VI0WbOR+fgPXGmg1OJIznUraqWCPhRruZ3Gy/s6DY2GbcPwEoHNjoOCBASn1Xu4ouKf68MvlzuHkAyBdq5k2Qv37DYBRLlQMiiaVPeac0YYiLSTiUQA89aH6WO6h3sW1prfmurZBhuXXa3cp0GfvQ73YfUBFXaUr6dwpt1HOmse+qDPRIE6YsKSAE4KPbAASPwy9pMsFokIwVgFfMLBKgRVfAdcldROznyzHL/vFb1bIrq6SfWm/vNt8U9ZGMsrmoMoWfuUSB60xAtyeBGhb+8Zt6N+9vX0rd6ihPJ1KepyJLFgVTjtR8eDvZExNh5oJqVSHZOfifyZ+LXE4WI79U13NoNrT8BxAeIwLn5TzLvNYoskpmVyDs5BKCLbWe8ZNHVPbKf02u1vAG+gjk6yxvFy5RfWJsAMwatd5gbPZORrmSscoljuyWId3RJ/taNY9HTzgUQBBOwvuNnzoKGU1aA7aG/S9O+Qen931+v0PKGx8Cl65k7jebbPgnLGYIixPuBt7oWrSODbFwlQYH03m4QpEv2G7fKJCntu7pyhhz9DAyF1NAuxjuB2yxoh/QeL/ggGE8x51Gl0wzn1WS/gXdNidOa3L0iGAXupy cZegQK9h tsV3JD4/qpuLp/0cQWv5t+sd9uDQFgcmucpkfo8ofFtkqB+3re3p0lNdeN+yNTw3XrgiD36VfjU70F5rMOMU4JmIbDcdH23+tT9WbtUQeAeDzce2dsrxi38bb5L+0Y0SbJ/0KTXAevSxyPsFsRdGPIW+aBBaho1GRwiCRvlCDhyJXp1y1EUyGHillW+UcQhZ9QU4op52Bek+f5o3NSjwIpIfh5XciqpNFjOsi2jYjFDyBOhqOqbsP5SlTe5hmZ13wryaIlSM2MKudO8B1RsNdVaZg0xxGOLb4GLq+Pm6fqrXT/4ELFEjnQcXf+SrL0v3Ycu0B2qCHKIJ2/cNMtN0NahWCiI1rFFh2YFFG9LwXo0IdxNY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000041, 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 Mon, Jan 22, 2024 at 6:35=E2=80=AFAM Lance Yang wr= ote: > > 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 aligns= 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 time > > > and what somebody considers good ATM might turn int "trying harder th= an > > > 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 actu= al > > > allocation/compaction implementation might change as well over time b= ut > > > the userspace at least knows that the request will not block waiting = for > > > any required resources. > > > > I appreciate your insights! > > > > It makes sense that a non-blocking semantic is easier to define and mai= ntain, > > providing userspace with the certainty that requests won=E2=80=99t be b= locked. > > > > Thanks, > > Lance > > > > > > > > -- > > > Michal Hocko > > > SUSE Labs