[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180702103601.GG19043@dhcp22.suse.cz>
Date: Mon, 2 Jul 2018 12:36:01 +0200
From: Michal Hocko <mhocko@...nel.org>
To: John Hubbard <jhubbard@...dia.com>
Cc: Leon Romanovsky <leon@...nel.org>, Jan Kara <jack@...e.cz>,
Jason Gunthorpe <jgg@...pe.ca>,
Dan Williams <dan.j.williams@...el.com>,
Christoph Hellwig <hch@....de>,
John Hubbard <john.hubbard@...il.com>,
Matthew Wilcox <willy@...radead.org>,
Christopher Lameter <cl@...ux.com>,
Linux MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-rdma <linux-rdma@...r.kernel.org>
Subject: Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()
On Sun 01-07-18 23:41:21, John Hubbard wrote:
> On 07/01/2018 11:34 PM, Leon Romanovsky wrote:
> > On Sun, Jul 01, 2018 at 11:10:04PM -0700, John Hubbard wrote:
[...]
> >>> Sorry for naive question, but won't it create too much dirty pages
> >>> so writeback will be called "non-stop" to rebalance watermarks without
> >>> ability to progress?
> >>>
> >>
> >> That is an interesting point.
> >>
> >> Holding off page writeback of this region does seem like it could cause
> >> problems under memory pressure. Maybe adjusting the watermarks so that we
> >> tell the writeback system, "all is well, just ignore this region until
> >> we're done with it" might help? Any ideas here are welcome...
> >
> > AFAIR, it is per-zone, so the solution to count dirty-but-untouchable
> > number of pages to take them into account for accounting can work, but
> > it seems like an overkill. Can we create special ZONE for such gup
> > pages, or this is impossible too?
> >
>
> Let's see what Michal and others prefer. The zone idea intrigues me.
No new zones please. Pinned pages are essentially mlocked pages, except
they are worse because they cannot be even migrated. What we really
needs is a) limit their usage and b) have a way to find out that pins
are not ephemeral and a special action needs to be taken. What is that
special action is yet to be decided but please do not add even more
complexity on top.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists