All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hillf Danton <hdanton@sina.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Tim Murray <timmurray@google.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Daniel Colascione <dancol@google.com>,
	Shakeel Butt <shakeelb@google.com>,
	Sonny Rao <sonnyrao@google.com>,
	Brian Geffon <bgeffon@google.com>
Subject: Re: [RFC 1/7] mm: introduce MADV_COOL
Date: Wed, 29 May 2019 16:52:00 +0800	[thread overview]
Message-ID: <20190529085200.13444-1-hdanton@sina.com> (raw)


On Wed, 29 May 2019 13:05:52 +0800 Michal Hocko wrote:
> On Wed 29-05-19 10:40:33, Hillf Danton wrote:
> > On Wed, 29 May 2019 00:11:15 +0800 Michal Hocko wrote:
> > > On Tue 28-05-19 23:38:11, Hillf Danton wrote:
> > > > 
> > > > In short, I prefer to skip IO mapping since any kind of address range
> > > > can be expected from userspace, and it may probably cover an IO mapping.
> > > > And things can get out of control, if we reclaim some IO pages while
> > > > underlying device is trying to fill data into any of them, for instance.
> > > 
> > > What do you mean by IO pages why what is the actual problem?
> > > 
> > Io pages are the backing-store pages of a mapping whose vm_flags has
> > VM_IO set, and the comment in mm/memory.c says:
> >         /*
> >          * Physically remapped pages are special. Tell the
> >          * rest of the world about it:
> >          *   VM_IO tells people not to look at these pages
> >          *      (accesses can have side effects).
> > 
> 
> OK, thanks for the clarification of the first part of the question. Now
> to the second and the more important one. What is the actual concern?
> AFAIK those pages shouldn't be on LRU list.

The backing pages for GEM object are lru pages, see the function
drm_gem_get_pages() in drivers/gpu/drm/drm_gem.c, please.

> If they are then they should
> be safe to get reclaimed otherwise we would have a problem when
> reclaiming them on the normal memory pressure.

Yes, Sir, they could be swapped out.

> Why is this madvise any different?

Now, it is not, thanks to the light you are casting.

BR
Hillf


             reply	other threads:[~2019-05-29  8:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29  8:52 Hillf Danton [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-05-29  2:40 [RFC 1/7] mm: introduce MADV_COOL Hillf Danton
2019-05-29  5:05 ` Michal Hocko
2019-05-28 15:38 Hillf Danton
2019-05-28 16:11 ` Michal Hocko
2019-05-28 12:15 Hillf Danton
2019-05-28 12:39 ` Minchan Kim
2019-05-20  3:52 [RFC 0/7] introduce memory hinting API for external process Minchan Kim
2019-05-28  8:53 ` [RFC 1/7] mm: introduce MADV_COOL Hillf Danton
2019-05-28  8:53   ` Hillf Danton
2019-05-20  3:52     ` Minchan Kim
2019-05-20  8:16     ` Michal Hocko
2019-05-20  8:19       ` Michal Hocko
2019-05-20 15:08         ` Suren Baghdasaryan
2019-05-20 15:08           ` Suren Baghdasaryan
2019-05-20 22:55         ` Minchan Kim
2019-05-20 22:54       ` Minchan Kim
2019-05-21  6:04         ` Michal Hocko
2019-05-21  9:11           ` Minchan Kim
2019-05-21 10:05             ` Michal Hocko
2019-05-28 10:58     ` Minchan Kim

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=20190529085200.13444-1-hdanton@sina.com \
    --to=hdanton@sina.com \
    --cc=akpm@linux-foundation.org \
    --cc=bgeffon@google.com \
    --cc=dancol@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=shakeelb@google.com \
    --cc=sonnyrao@google.com \
    --cc=surenb@google.com \
    --cc=timmurray@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.