[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF6AEGt8LXUwCiin5Z0Tab-9U66N22aZBVXM5aLFw8pjMXRgNQ@mail.gmail.com>
Date: Thu, 15 May 2025 10:36:27 -0700
From: Rob Clark <robdclark@...il.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Rob Clark <robdclark@...omium.org>, phasta@...nel.org,
dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
linux-arm-msm@...r.kernel.org, Connor Abbott <cwabbott0@...il.com>,
Matthew Brost <matthew.brost@...el.com>,
Christian König <ckoenig.leichtzumerken@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 04/40] drm/sched: Add enqueue credit limit
On Thu, May 15, 2025 at 10:23 AM Danilo Krummrich <dakr@...nel.org> wrote:
>
> On Thu, May 15, 2025 at 09:15:08AM -0700, Rob Clark wrote:
> > Basically it is a way to throttle userspace to prevent it from OoM'ing
> > itself. (I suppose userspace could throttle itself, but it doesn't
> > really know how much pre-allocation will need to be done for pgtable
> > updates.)
>
> I assume you mean prevent a single process from OOM'ing itself by queuing up
> VM_BIND requests much faster than they can be completed and hence
> pre-allocations for page tables get out of control?
Yes
Powered by blists - more mailing lists