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=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=no 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 16ED1C33CB6 for ; Wed, 22 Jan 2020 23:39:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8A5021835 for ; Wed, 22 Jan 2020 23:39:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="WZJFiO4N" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8A5021835 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 627866B0005; Wed, 22 Jan 2020 18:39:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D8836B0006; Wed, 22 Jan 2020 18:39:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CAD66B0007; Wed, 22 Jan 2020 18:39:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id 37A046B0005 for ; Wed, 22 Jan 2020 18:39:20 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id E660E181AEF0B for ; Wed, 22 Jan 2020 23:39:19 +0000 (UTC) X-FDA: 76406888838.29.flame76_3451a21089b34 X-HE-Tag: flame76_3451a21089b34 X-Filterd-Recvd-Size: 5158 Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Jan 2020 23:39:19 +0000 (UTC) Received: by mail-pg1-f194.google.com with SMTP id z124so340298pgb.13 for ; Wed, 22 Jan 2020 15:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=YNvajkPj2BUn62eVSIlq+7puNDrKQpZK5MXXRGczBsE=; b=WZJFiO4NDHzrXRTXfEk15plzqfBCf/XF0WnvEGStfqkfZ8Fj/EQr8PPvQ1mLAYqSCP v+tE914RPXI/94X6Y2Ek89gj39gHYxA1NTi3sKa6IgtxsqR7fEYjau6jIW00dazgJtqm NZx1MnFTfqkmUSUZZeskkvhavOEJCNt5fV+mYrZt5vPpBAD/vBNFA/RgfJYLX8D9PJaA G3KnjIHOycLCS+ldcv/ah1Uk5FmX3GkTjliBdERDyczvEhEsSyWkRdr9Dv0Y86tQcqZ1 /LhnvAT2PoZqjNrkdXKx4QNEIv+ukhBvwK0989ik3JobGkgCQ3qE+FM9Wjg3YeOp+dJQ Gk/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=YNvajkPj2BUn62eVSIlq+7puNDrKQpZK5MXXRGczBsE=; b=Kvdr4Fbvy41r2jSI+3XXbc5Dsrtn5n6LkCxOgbdTEeLo4sHQbaBL/nvK+aCi7YxL0T DBIEnyzhkiFMMT4FnjiMnpAQok/5pbNh9H/lPI1jtAkQT792buouW0f/7j6jonYmlMQA rFswaTt65lQ3PjbIVNu2YSiFLTPoE8hwF02yz2vkFX2d7926Xq0Xzcw8sWYYpxbsaT5w 5mJwblSD5BUQC8LlIFtbKNwrD5JuqR4YNHifCX1Jj4oImah7Og22SvUe8vhooBIePd1R XrHq+8LUkN9kqvo+71XhsGLX3E4u1rFPJYSb24Da4/AQAxWvjXqs5Ifd/yk+9RpdzOPg kNWA== X-Gm-Message-State: APjAAAVHJ+hifG7m6sZVK9xBLhqbaw2vHm4A+eGxNIcsh0irHYaG4SY5 Jz82NcFCtu2hGkBNbyi9WrXBgg== X-Google-Smtp-Source: APXvYqzYKfqD7EIYVVlkhEXDYVigv+4+OFhdSez6pqm4NRA/CZmbpyFtyH7DKP240xSGf/Xi6bieBA== X-Received: by 2002:a62:e80a:: with SMTP id c10mr4833932pfi.91.1579736358110; Wed, 22 Jan 2020 15:39:18 -0800 (PST) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id m101sm98110pje.13.2020.01.22.15.39.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jan 2020 15:39:17 -0800 (PST) Date: Wed, 22 Jan 2020 15:39:16 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Michal Hocko cc: Andrew Morton , Wei Yang , hannes@cmpxchg.org, vdavydov.dev@gmail.com, ktkhai@virtuozzo.com, kirill.shutemov@linux.intel.com, yang.shi@linux.alibaba.com, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, alexander.duyck@gmail.com, stable@vger.kernel.org Subject: Re: [Patch v4] mm: thp: remove the defer list related code since this will not happen In-Reply-To: <20200122081406.GO29276@dhcp22.suse.cz> Message-ID: References: <20200117233836.3434-1-richardw.yang@linux.intel.com> <20200118145421.0ab96d5d9bea21a3339d52fe@linux-foundation.org> <20200120072237.GA18451@dhcp22.suse.cz> <20200120212726.GB29276@dhcp22.suse.cz> <20200122081406.GO29276@dhcp22.suse.cz> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 22 Jan 2020, Michal Hocko wrote: > > The current code in 5.4 from commit 87eaceb3faa59 places any migrated > > compound page onto the deferred split queue of the destination memcg > > regardless of whether it has a mapping pmd > > (list_empty(page_deferred_list()) was already false) or it does not have a > > mapping pmd (but is now on the wrong queue). For the latter, > > can_split_huge_page() can help for the actual split but not for the > > removal of the page that is now erroneously on the queue. > > Does that mean that those fully mapped THPs are not going to be split? > It believe it should but deferred_split_scan() also won't take it off the wrong split queue so it will remain there and any other checks for page_deferred_list(page) will succeed. > > For the former, > > memcg reclaim would not see the pages that it should split under memcg > > pressure so we'll see the same memcg oom conditions we saw before the > > deferred split shrinker became SHRINKER_MEMCG_AWARE: unnecessary ooms. > > OK, this is yet another user visibile effect and it would be better to > mention it explicitly in the changelog. > Ok, feel free to add to the last paragraph: Memcg reclaim would not see the compound pages that it should split under memcg pressure so we'll otherwise see the same memcg oom conditions we saw before the deferred split shrinker became SHRINKER_MEMCG_AWARE: unnecessary ooms.