From: Chris Wilson <chris@chris-wilson.co.uk>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: intel-gfx@lists.freedesktop.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Kuo-Hsin Yang <vovoy@chromium.org>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH v7] mm, drm/i915: mark pinned shmemfs pages as unevictable
Date: Wed, 07 Nov 2018 15:34:51 +0000 [thread overview]
Message-ID: <154160489128.4321.4951578054574913878@skylake-alporthouse-com> (raw)
In-Reply-To: <20181106101211.d2e4857aa36ea8ffbd870d2f@linux-foundation.org>
Quoting Andrew Morton (2018-11-06 18:12:11)
> On Tue, 6 Nov 2018 13:23:24 +0000 Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> > From: Kuo-Hsin Yang <vovoy@chromium.org>
> >
> > The i915 driver uses shmemfs to allocate backing storage for gem
> > objects. These shmemfs pages can be pinned (increased ref count) by
> > shmem_read_mapping_page_gfp(). When a lot of pages are pinned, vmscan
> > wastes a lot of time scanning these pinned pages. In some extreme case,
> > all pages in the inactive anon lru are pinned, and only the inactive
> > anon lru is scanned due to inactive_ratio, the system cannot swap and
> > invokes the oom-killer. Mark these pinned pages as unevictable to speed
> > up vmscan.
> >
> > Export pagevec API check_move_unevictable_pages().
> >
> > This patch was inspired by Chris Wilson's change [1].
> >
> > [1]: https://patchwork.kernel.org/patch/9768741/
> >
> > ...
> >
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2382,12 +2382,26 @@ void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj)
> > invalidate_mapping_pages(mapping, 0, (loff_t)-1);
> > }
> >
> > +/**
>
> This token is used to introduce a kerneldoc comment.
>
> > + * Move pages to appropriate lru and release the pagevec. Decrement the ref
> > + * count of these pages.
> > + */
>
> But this isn't a kerneldoc comment.
>
> At least, I don't think it is. Maybe the parser got smarter when I
> wasn't looking.
>
> > +static inline void check_release_pagevec(struct pagevec *pvec)
> > +{
> > + if (pagevec_count(pvec)) {
> > + check_move_unevictable_pages(pvec);
> > + __pagevec_release(pvec);
> > + cond_resched();
> > + }
> > +}
>
> This looks too large to be inlined and the compiler will ignore the
> `inline' anyway.
Applied both corrections.
> Otherwise, Acked-by: Andrew Morton <akpm@linux-foundation.org>. Please
> go ahead and merge via the appropriate drm tree.
Thank you, pushed to drm-intel, expected to arrive around 4.21.
-Chris
prev parent reply other threads:[~2018-11-07 15:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-06 9:30 [PATCH v6] " Kuo-Hsin Yang
2018-11-06 10:54 ` Daniel Vetter
2018-11-06 15:19 ` Kuo-Hsin Yang
2018-11-06 11:06 ` Chris Wilson
2018-11-06 11:49 ` Kuo-Hsin Yang
2018-11-06 12:14 ` Michal Hocko
2018-11-06 13:23 ` [PATCH v7] " Chris Wilson
2018-11-06 14:14 ` Kuo-Hsin Yang
2018-11-06 17:32 ` Dave Hansen
2018-11-06 18:12 ` Andrew Morton
2018-11-07 15:34 ` Chris Wilson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=154160489128.4321.4951578054574913878@skylake-alporthouse-com \
--to=chris@chris-wilson.co.uk \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=vovoy@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox