From: Yang Shi <email@example.com> To: Dave Hansen <firstname.lastname@example.org>, Greg Thelen <email@example.com>, Dave Hansen <firstname.lastname@example.org>, email@example.com Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [RFC][PATCH 2/8] mm/migrate: Defer allocating new page until needed Date: Wed, 1 Jul 2020 11:32:32 -0700 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On 7/1/20 7:46 AM, Dave Hansen wrote: > On 7/1/20 1:47 AM, Greg Thelen wrote: >> Dave Hansen <email@example.com> wrote: >>> From: Keith Busch <firstname.lastname@example.org> >>> 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 <email@example.com> >> 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.
next prev parent reply index Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-29 23:45 [RFC][PATCH 0/8] Migrate Pages in lieu of discard Dave Hansen 2020-06-29 23:45 ` [RFC][PATCH 1/8] mm/numa: node demotion data structure and lookup Dave Hansen 2020-06-29 23:45 ` [RFC][PATCH 2/8] mm/migrate: Defer allocating new page until needed Dave Hansen 2020-07-01 8:47 ` Greg Thelen 2020-07-01 14:46 ` Dave Hansen 2020-07-01 18:32 ` Yang Shi [this message] 2020-06-29 23:45 ` [RFC][PATCH 3/8] mm/vmscan: Attempt to migrate page in lieu of discard Dave Hansen 2020-07-01 0:47 ` David Rientjes 2020-07-01 1:29 ` Yang Shi 2020-07-01 5:41 ` David Rientjes 2020-07-01 8:54 ` Huang, Ying 2020-07-01 18:20 ` Dave Hansen 2020-07-01 19:50 ` David Rientjes 2020-07-02 1:50 ` Huang, Ying 2020-07-01 15:15 ` Dave Hansen 2020-07-01 17:21 ` Yang Shi 2020-07-01 19:45 ` David Rientjes 2020-07-02 10:02 ` Jonathan Cameron 2020-07-01 1:40 ` Huang, Ying 2020-07-01 16:48 ` Dave Hansen 2020-07-01 19:25 ` David Rientjes 2020-07-02 5:02 ` Huang, Ying 2020-06-29 23:45 ` [RFC][PATCH 4/8] mm/vmscan: add page demotion counter Dave Hansen 2020-06-29 23:45 ` [RFC][PATCH 5/8] mm/numa: automatically generate node migration order Dave Hansen 2020-06-30 8:22 ` Huang, Ying 2020-07-01 18:23 ` Dave Hansen 2020-07-02 1:20 ` Huang, Ying 2020-06-29 23:45 ` [RFC][PATCH 6/8] mm/vmscan: Consider anonymous pages without swap Dave Hansen 2020-06-29 23:45 ` [RFC][PATCH 7/8] mm/vmscan: never demote for memcg reclaim Dave Hansen 2020-06-29 23:45 ` [RFC][PATCH 8/8] mm/numa: new reclaim mode to enable reclaim-based migration Dave Hansen 2020-06-30 7:23 ` Huang, Ying 2020-06-30 17:50 ` Yang Shi 2020-07-01 0:48 ` Huang, Ying 2020-07-01 1:12 ` Yang Shi 2020-07-01 1:28 ` Huang, Ying 2020-07-01 16:02 ` Dave Hansen 2020-07-03 9:30 ` Huang, Ying 2020-06-30 18:36 ` [RFC][PATCH 0/8] Migrate Pages in lieu of discard Shakeel Butt 2020-06-30 18:51 ` Dave Hansen 2020-06-30 19:25 ` Shakeel Butt 2020-06-30 19:31 ` Dave Hansen 2020-07-01 14:24 ` [RFC] [PATCH " Zi Yan 2020-07-01 14:32 ` Dave Hansen
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
Linux-mm Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-mm/0 linux-mm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-mm linux-mm/ https://lore.kernel.org/linux-mm \ email@example.com public-inbox-index linux-mm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kvack.linux-mm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git