[lkml]   [2020]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 2/8] mm/migrate: Defer allocating new page until needed
On 7/1/20 1:47 AM, Greg Thelen wrote:
> Dave Hansen <> wrote:
>> From: Keith Busch <>
>> 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.

>> #Signed-off-by: Keith Busch <>
> Is commented Signed-off-by intentional? Same applies to later patches.

Yes, Keith is no longer at Intel, so that mail would bounce.
I left the 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.

 \ /
  Last update: 2020-07-01 16:47    [W:0.107 / U:3.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site