On 7/1/20 7:46 AM, Dave Hansen wrote:
On 7/1/20 1:47 AM, Greg Thelen wrote:
Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> wrote:
From: Keith Busch <kbusch@xxxxxxxxxx>
Defer allocating the page until we are actually ready to make use of
it, after locking the original page. This simplifies error handling,
but should not have any functional change in behavior. This is just
refactoring page migration so the main part can more easily be reused
by other code.
Is there any concern that the src page is now held PG_locked over the
dst page allocation, which might wander into
reclaim/cond_resched/oom_kill? I don't have a deadlock in mind. I'm
just wondering about the additional latency imposed on unrelated threads
who want access src page.
It's not great. *But*, the alternative is to toss the page contents out
and let users encounter a fault and an allocation. They would be
subject to all the latency associated with an allocation, just at a
slightly later time.
If it's a problem it seems like it would be pretty easy to fix, at least
for non-cgroup reclaim. We know which node we're reclaiming from and we
know if it has a demotion path, so we could proactively allocate a
single migration target page before doing the source lock_page(). That
creates some other problems, but I think it would be straightforward.
If so this patch looks pointless if I read it correctly. The patch
defers page allocation in __unmap_and_move() under page lock so that
__unmap_and _move() can be called in reclaim path since the src page is
locked in reclaim path before calling __unmap_and_move() otherwise it
would deadlock itself.
Actually you always allocate target page with src page locked with this
implementation unless you move the target page allocation before
shrink_page_list(), but the problem is you don't know how many pages you
need allocate.
The alternative may be to unlock the src page then allocate target page
then lock src page again. But if so why not just call migrate_pages()
directly as I did in my series? It put the src page on a separate list
then unlock it, then migrate themn in batch later.
#Signed-off-by: Keith Busch <keith.busch@xxxxxxxxx>
Is commented Signed-off-by intentional? Same applies to later patches.
Yes, Keith is no longer at Intel, so that @intel.com mail would bounce.
I left the @intel.com SoB so it would be clear that the code originated
from Keith while at Intel, but commented it out to avoid it being picked
up by anyone's tooling.
