[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJuCfpHG9EWAC9p7hcOH6oPMWMMSDr91HDt7ZuX2M7=j6bxuGw@mail.gmail.com>
Date: Wed, 12 Mar 2025 09:06:02 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Sooyong Suk <s.suk@...sung.com>, Jaewon Kim <jaewon31.kim@...il.com>, viro@...iv.linux.org.uk,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, linux-mm@...ck.org,
spssyr@...il.com, axboe@...nel.dk, linux-block@...r.kernel.org,
dhavale@...gle.com
Subject: Re: [RFC PATCH] block, fs: use FOLL_LONGTERM as gup_flags for direct IO
On Wed, Mar 12, 2025 at 8:52 AM Christoph Hellwig <hch@...radead.org> 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.
>
Powered by blists - more mailing lists