[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1460410060.6473.574.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Mon, 11 Apr 2016 14:27:40 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Jesper Dangaard Brouer <brouer@...hat.com>
Cc: lsf@...ts.linux-foundation.org, Tom Herbert <tom@...bertland.com>,
Brenden Blanco <bblanco@...mgrid.com>,
James Bottomley <James.Bottomley@...senPartnership.com>,
linux-mm <linux-mm@...ck.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
lsf-pc@...ts.linux-foundation.org,
Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [Lsf] [LSF/MM TOPIC] Generic page-pool recycle facility?
On Mon, 2016-04-11 at 22:23 +0200, Jesper Dangaard Brouer wrote:
> If we have a page-pool recycle facility, then we could use the trick,
> right? (As we know that get_page_unless_zero() cannot happen for pages
> in the pool).
Well, if you disable everything that possibly use
get_page_unless_zero(), I guess this could work.
But then, you'll have to spy lkml traffic forever to make sure no new
feature is added in the kernel, using this get_page_unless_zero() in a
new clever way.
You could use a page flag so that z BUG() triggers if
get_page_unless_zero() is attempted on one of your precious pages ;)\
We had very subtle issues before my fixes (check
35b7a1915aa33da812074744647db0d9262a555c and children), so I would not
waste time on the lock prefix avoidance at this point.
Powered by blists - more mailing lists