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 D5083C28B28 for ; Wed, 12 Mar 2025 16:06:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9BEE0280005; Wed, 12 Mar 2025 12:06:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96D52280001; Wed, 12 Mar 2025 12:06:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81252280005; Wed, 12 Mar 2025 12:06:19 -0400 (EDT) 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 61DC0280001 for ; Wed, 12 Mar 2025 12:06:19 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B9B9F1CB377 for ; Wed, 12 Mar 2025 16:06:19 +0000 (UTC) X-FDA: 83213376078.21.FF1A6B4 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf05.hostedemail.com (Postfix) with ESMTP id 67BC0100024 for ; Wed, 12 Mar 2025 16:06:15 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pHpHekjY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741795575; a=rsa-sha256; cv=none; b=62130+PL3BDFKXz+GRIO3wJemSNwXrcFxkiNkW5MVvwMNb8Oci63DczAKjSJ9WmdZyU0Jx TMcRzho5DdDVqYi3Z3nAHrQ2ppovxxAQu9a4Yfg9rC9B1PJ/2JtEFp2P1p1JLh7oMZ2IAw 35JuRMujYRffGNgySYx+KcAKzhRXOPM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pHpHekjY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741795575; 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=WrwYv4hV0FSY3G0vHHh7TMbzsgf3mwWBIi9HSSg420o=; b=VVyaIlYKEIFJPH2j+Z+TSCowINLBoUEKDmPfIHKz+rPxHptod7f4MxMJ0NB+h8Jdwoj8q/ sjUmIbshGYvxIzvEsyW88CtvP6BrJYaweKPNw8ZlOxTUR8kM4lYnCXq7I7ZiCFxPA0tFhs vRHoE7kfl26KU/OxOc4CDgoZkNcT2Gs= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-47681dba807so225511cf.1 for ; Wed, 12 Mar 2025 09:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1741795574; x=1742400374; 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=WrwYv4hV0FSY3G0vHHh7TMbzsgf3mwWBIi9HSSg420o=; b=pHpHekjY75ix/H4pS/1S/vavVxG6ZJr/+Evi23r2AsAHLS4jHIE4kr/PjCbCisR3i9 2vg98S6yJxo3y/iEKTuVRIX27ZzEprMheZpPvx2LhSgzCJOgYtX6IjU/pkwqRMWr7WJA aVN6/J2ID6tRotHKr+UYsM5kkT7qcDqb/YP9Jpujk3d7yNel1OppWulQ3dwUOWXUY3xq Y7b5hWwWtGSyqdxwozFNrl7xcPSLC1QNe83d3fsQto1zx1YwwY0lEWFNwu3qGnuLXXgw Ryi0FvTiTU+7CrrHIFfOn8EUxEhRa+Tzapt5aQrCtRfwyEqu8c2v1vlszyzkxKEBu/8X SWzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741795574; x=1742400374; 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=WrwYv4hV0FSY3G0vHHh7TMbzsgf3mwWBIi9HSSg420o=; b=iepuHMxcmscTtwKGvbdT4RD/52JIOUfKWwZ8Is+HBQHtGAhFgBpyrD7DJZbR1h07Fn vqrKHvdK5wBwuddEi87avXQjdHfx/xTo7z+pZSsKTSZvgjX0eNK/n9aPjlBdKFz9Deew dXFGnyO9ldORDJVb4SnXE7V5j5PY7y7+9WJ5S0BJC14kCqyYEOm6SEGybJqCBWsen3LG bSdk/ys+V+l4WCjADhqRWDhApx6sYrEesdjKHYM3qDCjcTBwEIVuMHu75FzKvgEGVN+T TPdym5luKFy6N439ZpsBN1/WG/fdi7ReAXYxV3YSkL2cNFgC9wrlZESnaEtOmSOQbvkQ M6bw== X-Forwarded-Encrypted: i=1; AJvYcCWX/SZVml3+PJffNBc7M4SFu3bD344Yux+bBIGCXaBnaLOntXQOnaYfmPlJ/6+ltBXFKctxmGaO3g==@kvack.org X-Gm-Message-State: AOJu0Yxu9sJq+Z9Z3Iw7oZfW02A/gGCxi4xq5azjfwY8V3jL0fcvdyzG SvGbUQQ7PRpHYvNP8159kFNhGjtpGFhEBHRxlLETDGJEOj6nJw8AOQ/tzVA4mWs16ysx9Mb0Gcg 6OVsqyPpfS9unT6gphGVuT8gpxvkLIAuiRckz X-Gm-Gg: ASbGncvTG4GZxbIJW+iWvLSCAVqGGyZ1X/oYuk1wFhHSuOeiDbJq4EHmUVaflbHoypw yflQxuJxfUw+tJ3htA5hjaHJaC3MqA5l4W5gPqucHT+2CmKry/V/xbvtKeR0sw1Krn278L5ZHus f+sqBJziNtjqYQt/9GdzI2U2UMGbknO/ac9krTvdskMQRBjJvdMdKOL62P X-Google-Smtp-Source: AGHT+IFGXoN107iRcKAaMfh5q54qUSWhsZqDVFmtSnv/zuzK/6+/d0yI2gmYWt4umU7mYkJ4NKdYWUinvN1PCsVQ9g4= X-Received: by 2002:ac8:5846:0:b0:467:8416:d99e with SMTP id d75a77b69052e-476b7ade14dmr390451cf.21.1741795573844; Wed, 12 Mar 2025 09:06:13 -0700 (PDT) MIME-Version: 1.0 References: <20250306074056.246582-1-s.suk@samsung.com> <848301db8f05$a1d79430$e586bc90$@samsung.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 12 Mar 2025 09:06:02 -0700 X-Gm-Features: AQ5f1Joz69JkjpPsTbZTRmJZtQx_aT9cYAZCenCDm6y3j32d7IR3YQveqxicKU4 Message-ID: Subject: Re: [RFC PATCH] block, fs: use FOLL_LONGTERM as gup_flags for direct IO To: Christoph Hellwig Cc: Sooyong Suk , Jaewon Kim , viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, spssyr@gmail.com, axboe@kernel.dk, linux-block@vger.kernel.org, dhavale@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 67BC0100024 X-Rspamd-Server: rspam05 X-Stat-Signature: ysj3hxfubssc57ccm837ta5wf746uoaf X-HE-Tag: 1741795575-293984 X-HE-Meta: U2FsdGVkX19GqhN9Oa2FR7CmXwWtks51SItLFEFRkymdWGCp0iGZdqFXl9LuU1hVz/qjp2yZSZ05C7nLD4QMBueaZbx0tIRlqVe7NNzv1UWYT2q0rU+o0KFDxvjqSDopjJx1EpGz67OFAtPucVzIi142EPpIPGvYLnGXcDDDRfoFerxSI2Hb4QyUMuVZTgP93ySJxj9BhRwZIUMyD5+6kr4ysV6pdsGCf+WWGQqnpWOE9AY49sBtwq61wwTITKatlk76Z5SBkkfu/HdjA9ejTw0R2EhJvML91qW7ihDEmyWHA2Fa9g9BtmYIdAGUD5QkdSqM6VeG5qzDbtt0Q4dRiEYKkN6ZPPMnSi5h8tZaOFwkxqn6YT8S9cIi/4sDwHqsSe84Xc5KTz81cOUybpN4oi/aXTDigREw6Qh1AuxV6WbHfW+K380EiYmRSNfRcv+OJUzlbbZYrb4e7FnBpGYPDOpue0owY7jG+y27aF7qdiod9nk96AOAg1bHbz6Ijz29r0fldLpZrBDk4tCsNS54wC7Edhcmyk3o1iReuLP9dxLn4quwhWw16+r67Lx/zi40q3+jv2KHdhQ4QkVVG3t3c9e3HkRBvjPj5UmDd+21NYooOKCizU3HFkHU/yhF0z4OeCzbP0ql9PfFeIDTnUpzlYsAF0LKSWAcy+g27ZxMYPnnROPMo7NWAfJDHXnnH8X5+m+rW7pMXQPWFihzt24FbDe7tH4xXJfag8/2E4gS5G5bNEOj+rHvoYh8ZfbcmNuj+gvMHym17a58+mBtTHG3lwJiS94yha2MlrykR+9feEEK52uWVKYikwOYYFFFt+wtn+9RIdPZM8TIy8oX+3ourzyMM9gBkvlVPnX7B11UxoXTQ4KA7yIj8rpMCQHE8PihduxVyb77BOhgf3lqsbKQGKc0WoEsupvw06iUbXHunRCFkzVcM0/uhRLtAb3jVLwKIrV9SdsOaf04sE/3TCq gZkQwqlo zuGzi/zBN/gtdpwRkhXIRpW7IIEqm17cVWJ4PmJvdT2hhBVMW1WEDXmgo8Q== 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 Wed, Mar 12, 2025 at 8:52=E2=80=AFAM Christoph Hellwig wrote: > > On Wed, Mar 12, 2025 at 08:38:07AM -0700, Suren Baghdasaryan wrote: > > I might be wrong but my understanding is that we should try to > > allocate from CMA when the allocation is movable (not pinned), so that > > CMA can move those pages if necessary. I understand that in some cases > > a movable allocation can be pinned and we don't know beforehand > > whether it will be pinned or not. But in this case we know it will > > happen and could avoid this situation. > > Any file or anonymous folio can be temporarily pinned for I/O and only > moved once that completes. Direct I/O is one use case for that but there > are plenty others. I'm not sure how you define "beforehand", but the > pinning is visible in the _pincount field. Well, by "beforehand" I mean that when allocating for Direct I/O operation we know this memory will be pinned, so we could tell the allocator to avoid CMA. However I agree that FOLL_LONGTERM is a wrong way to accomplish that. > > > Yeah, low latency usecases for CMA are problematic and I think the > > only current alternative (apart from solutions involving HW change) is > > to use a memory carveouts. Device vendors hate that since carved-out > > memory ends up poorly utilized. I'm working on a GCMA proposal which > > hopefully can address that. > > I'd still like to understand what the use case is. Who does CMA > allocation at a time where heavy direct I/O is in progress? I'll let Samsung folks clarify their usecase. >