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 D6213C28B28 for ; Wed, 12 Mar 2025 15:38:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDE26280002; Wed, 12 Mar 2025 11:38:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8C4B280001; Wed, 12 Mar 2025 11:38:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C55C8280002; Wed, 12 Mar 2025 11:38:20 -0400 (EDT) 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 A40B7280001 for ; Wed, 12 Mar 2025 11:38:20 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id CA77F160FA1 for ; Wed, 12 Mar 2025 15:38:21 +0000 (UTC) X-FDA: 83213305602.21.5C125E6 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf10.hostedemail.com (Postfix) with ESMTP id EB23BC0009 for ; Wed, 12 Mar 2025 15:38:19 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KONsac+Q; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=surenb@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=1741793899; 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=oad3olm2GEdFBtEEysjN3502N0ME3OM6JNCjW+ME63A=; b=16Bw3R4yWNT03nf4CuIEqAkNBWdKPVmgJQbUwpWClk72eKlI61KgtwWV3dijAYKsU2azRb XU2G+/UrV3fCZUr/gCCEYAzxxtcWhQKHLLx+IeLELUCHdWS5qcaTn8CEXZEImt1gUTNQ5P YKILJtL5TO79JbiTLLTLQigkwif8Dpc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741793900; a=rsa-sha256; cv=none; b=3YBRY0mWIWnDNRmHp+2vug+5gnrzTCn2a9FWvvAMfujQGF26P3SxXM+Voft+t0vOXUVUTf KVehoSofGWh7MBYnyKeUOqH6XMwfj2rK7n8eU/bmAvqk6ov52DF6vJqE006lzl8Gne/up1 dUFLHwUEvXKFFWIT3Uly06p9DuaOT2c= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KONsac+Q; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-47681dba807so215851cf.1 for ; Wed, 12 Mar 2025 08:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1741793899; x=1742398699; 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=oad3olm2GEdFBtEEysjN3502N0ME3OM6JNCjW+ME63A=; b=KONsac+Q1CHsB7E+3BjMBHjg/oy/jLX4Xe6D++8sXs0HdIlVZ/oDLytRLQZstB5VlU tZ4P8lwPUs/79YIplVbXzjzVFUxaRzBZR/qlf0bkbs1XxxRjC73FVyi5S3vRjHgxrosp cS4CARd3fz8h9/YtBlDJ4JFYwJsDgsScGbzEzq54mRF4xBqVM+I3JcBINKQMIoOoj0Kq esHPZigzXD8V1vXCiKX1LQpvb4exP+E4Ta7f704cn4CeUR5Zvncju2I6pZLeRofi9R6I M/aUjhnhJ8NTGn+aKcMtMoLovsxkZFyqHLDkePuRAI3U4P6J90P6EWkmyTFF1gLDenP3 o9yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741793899; x=1742398699; 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=oad3olm2GEdFBtEEysjN3502N0ME3OM6JNCjW+ME63A=; b=IKnW26m3tpzcTYf76wRRd7z2O67sruMwDWloDvf3f35gErY0AQic1ymFkgZyTAO5LM zqTR+uHT1MkORJ4+D4DMhZot22hcSmSZUd/mLH8lBIGicxa5xuOrhWOgrcO4p8gTFltF QrijQNa+bcZf4fS7j9U9ppwJHN6KQVH+/+JeLuLAoQ9CxB2/o6lhG8RePdozYIWBSOfN hZgL8qTiLeHoG1PkHshCspJTEGMKYA73c7bkcCKDQ6ZJhYh7niVOMaLNOnKwOACDLmFN o2+qLATk5jPn75Vfy6z2DGAxrTjCwDzYI9aB7noLomf9JFRwVhyuVK7OPrOTcQWhSaEM nwow== X-Forwarded-Encrypted: i=1; AJvYcCWYdEA/AEUBkY26wx7VTeXqgjYe+4UBj8855vjDsQANlWw3gDmMbrxcqnpUWSboEUVwMTc55HwFpQ==@kvack.org X-Gm-Message-State: AOJu0Yw9gwpFpRDl+H2B/7cEL4loA7Uo742hy2VRH4KmTD0Nb8UC0t3C Yd47WqfdN2tAqS1HOHbTWU1vC0lT6Ffbh8XRFSbzDUY0qVAMvtluQuEMMZfCTswxujyus33/342 WokSrIbQldVOhImxVQZm4HiLDGF09intF2Z3e X-Gm-Gg: ASbGncudtJOld43BP3HOcTDx2Nhy2/xxu5UmIgfuwKlTW2do0ZDBi4TkUbO7dfeeCsY /6eFvhj1Sp1acxjc3Dou1HpRLNiOIYoyw6O1N10550Lsoovku23wmuV1hqRWPXb+LsgKSTj6uxI zrB/bvulHWkQfU4fJul1MXB6V1ZrnGTU911aoRsHKXwHGR8uIXgAljnoR+EFr/CFHQq7Q= X-Google-Smtp-Source: AGHT+IFQd7cFv173t000O1zcn+8wgPx4dJlGWMBi427eiMql7l9Xmf0NxuFYWlaUbMq6ERIxoPYFIgYpzBuguiARoR4= X-Received: by 2002:ac8:5a95:0:b0:472:538:b795 with SMTP id d75a77b69052e-476b798f0admr328451cf.22.1741793898834; Wed, 12 Mar 2025 08:38:18 -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 08:38:07 -0700 X-Gm-Features: AQ5f1Jpfs-45rUWpy4AjGITfWFgctjNpl6Oq04S9EIvxgwjOZng3y_psNvrHlmM 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-Server: rspam02 X-Rspamd-Queue-Id: EB23BC0009 X-Stat-Signature: p16shz7gh34gzfcwniqfxosg1r78bhfe X-HE-Tag: 1741793899-856058 X-HE-Meta: U2FsdGVkX1+8/FFcrDDJo7BlMOBSIMw/lin+Bp5iFHLIfWxwWrdcaBJpK54j/cMwxvn5SqhUtuJWJ6/wsaJDGzWxpFGfUzHFgeYbiprfF4pyZuWb0xojTbVQNFGqgSAWe8jE8FpWejlFUzS8FngQHCRX1Y+YgxeC8NdL7OLZpajSPYkjWtBXiOEZE5Ujy+fZYiRMrXHjSmo86EubWciUMkEg9jcHb+cbyuZo83SGM6UInaG3z2i6H22KreJ5w6Y7gzVOEnFmvsUtZf5bfgfnS74pBdRe763imLovUjlHg9BIbFcmvW5GemMqfIMIzEACEbuz9syFlKdes4NOCTQsz5TtMExf2zSQ/TcJFPEk61ev4It99JU1h/kmylb8LwIQ+EoGuDN4fbUruV9bI2Z7xZ+NcmLSYPRRtMltjEXdy5e8rNeT/7s7vela6ZQmRg4rZY8B1Pcq7LOjA2MPKTx6f6M+d5GNxFhs50KFQ70tjqL70mzgc2Fl7nSp+xyw6FUVhKDR6MwxIR0pz9zcNqT9i+qxrI+cTiXEmnBmWRerb9lhbGQ9bGPYkObkHVA58UtcZciN36RCaw8HI4+oxkrf7lmNOFz088u0tJO1yXkU6OZPMRZ9/MoWtVxsSDi5l2AdPvI8m73vFKDEmdUtHJu62QaxCB/3aeIwSFquSdhnmFstInvCxfYn0EgX3pOpWitEkykFABoJsqjT2qa2/o35jhH+YvA9PD0CP9golIAZ1+LtWOBhfnzJ8foUl3D0dq723BApZCHS45ze/mR9h+t/I8P3EPyPpC1Xtx9SJayCAZQ7j5Zxy619SfDxZufWNHRhvnvlluzZNmpLABbhoDdclFFwGVVwwWCYb8T9P0tStchdIQOGbTxCs0RM0/omJNrvWS/kiwKscE6Ou6AdpG7mIAmIjrKvIJNqJ07Cp1fhu2K7DFNaix0J6AFwGyji7gPXPfIC2gQys2QQT8+o9Jc RFk3CFfa MrMYJmDy9JEhUj2UMDgh+tolmbcLSQ1MgOd7QKVoCrTXQMPeSYX5Yshgz4bEjyqobJRspziV4U6/SKAHP3yieTvAt8449BY6GrDvHoExoT8V0TaN2MCo4uF48QKq7Opl4poLngyCPemN0wbTNilIlo4rDtfT4EA69fL31ZIKhHqy7Ny68SABo22J7lmzmAc+CVlLqxfge4b1oZBz4YoAm1tN7dTfLRxufrz13BFoC82GNucZM64QVwKCfWn0qVcHZf9udgfzgu3jc6gA6zly4/3tC4tuUArRQqcfpZIUS2p3nIYBJOtN+AR28C62VTNlVr/HjRn0Y6cTqb+a7HVUKIJszq4KfbYhyhkYSN262HLkVWTWYXjvSUFI0tg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000045, 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:25=E2=80=AFAM Christoph Hellwig wrote: > > On Wed, Mar 12, 2025 at 08:20:36AM -0700, Suren Baghdasaryan wrote: > > > Direct I/O pages are not unmovable. They are temporarily pinned for > > > the duration of the direct I/O. > > > > Yes but even temporarily pinned pages can cause CMA allocation > > failure. My point is that if we know beforehand that the pages will be > > pinned we could avoid using CMA and these failures would go away. > > Direct I/O (and other users of pin_user_pages) are designed to work > on all anonymous and file backed pages, which is kinda the point. > If you CMA user can't wait for the time of an I/O something is wrong > with that caller and it really should not use CMA. 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. 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. >