From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 507BDC433E0 for ; Wed, 1 Jul 2020 18:32:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 217DA207F5 for ; Wed, 1 Jul 2020 18:32:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 217DA207F5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B0EEA6B0081; Wed, 1 Jul 2020 14:32:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A979B6B0082; Wed, 1 Jul 2020 14:32:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 987BB6B0083; Wed, 1 Jul 2020 14:32:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id 7FF566B0081 for ; Wed, 1 Jul 2020 14:32:58 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DECFF2DFA for ; Wed, 1 Jul 2020 18:32:57 +0000 (UTC) X-FDA: 76990353594.18.robin31_631673826e82 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id B6039100EDBE1 for ; Wed, 1 Jul 2020 18:32:57 +0000 (UTC) X-HE-Tag: robin31_631673826e82 X-Filterd-Recvd-Size: 4244 Received: from out30-43.freemail.mail.aliyun.com (out30-43.freemail.mail.aliyun.com [115.124.30.43]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Wed, 1 Jul 2020 18:32:56 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01355;MF=yang.shi@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0U1QNcAa_1593628370; Received: from US-143344MP.local(mailfrom:yang.shi@linux.alibaba.com fp:SMTPD_---0U1QNcAa_1593628370) by smtp.aliyun-inc.com(127.0.0.1); Thu, 02 Jul 2020 02:32:53 +0800 Subject: Re: [RFC][PATCH 2/8] mm/migrate: Defer allocating new page until needed To: Dave Hansen , Greg Thelen , Dave Hansen , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, kbusch@kernel.org, rientjes@google.com, ying.huang@intel.com, dan.j.williams@intel.com References: <20200629234503.749E5340@viggo.jf.intel.com> <20200629234507.CA0FDE19@viggo.jf.intel.com> <977d6482-58f8-c1c8-c54d-7c03a028c532@intel.com> From: Yang Shi Message-ID: <9da66966-1f67-13ce-28c2-281b37147568@linux.alibaba.com> Date: Wed, 1 Jul 2020 11:32:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <977d6482-58f8-c1c8-c54d-7c03a028c532@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: B6039100EDBE1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000347, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 7/1/20 7:46 AM, Dave Hansen wrote: > 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. 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 >> 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.