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=-12.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 85E35C33CB6 for ; Sat, 18 Jan 2020 23:36:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4A469246AC for ; Sat, 18 Jan 2020 23:36:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="iu115+9l" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A469246AC 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 D94DC6B053C; Sat, 18 Jan 2020 18:36:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D1FE16B053D; Sat, 18 Jan 2020 18:36:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE7CA6B053E; Sat, 18 Jan 2020 18:36:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0152.hostedemail.com [216.40.44.152]) by kanga.kvack.org (Postfix) with ESMTP id A689C6B053C for ; Sat, 18 Jan 2020 18:36:10 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 365784995F6 for ; Sat, 18 Jan 2020 23:36:10 +0000 (UTC) X-FDA: 76392365700.27.ear39_52e6beb580059 X-HE-Tag: ear39_52e6beb580059 X-Filterd-Recvd-Size: 5866 Received: from mail-pj1-f65.google.com (mail-pj1-f65.google.com [209.85.216.65]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Sat, 18 Jan 2020 23:36:09 +0000 (UTC) Received: by mail-pj1-f65.google.com with SMTP id n59so5185496pjb.1 for ; Sat, 18 Jan 2020 15:36:09 -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=uIkVi5/18BrXAFhDrVTXIWex0kk8NMAn2RkTWk0CSSY=; b=iu115+9lV/04EU32wHPVpF5SDtYyBN/ZzP+6hYsCU3Loxosw509E7TMGGGSST3zeco midRiRU45Kip2a5+PVlNYHG5rnRUAbAya88HCQLSqJXOSRpyh5D5ysfQA5zKL6VN9cjo YFLcul8JrbJIRsTxm9W8BTYuu3mU+NggVPgGJ9oWUH5JAgZl/jl6BaXT+mi8ElktC7eP K9uDl0rvufOE+biNXeyhrorGReyOFLb9SLyQGcLRZd1fvH03NkUt5aPxE9CraNLEZ1eK HAbBTyicLdpaAK/ntvqjoTh0C0873jNLJNI1hXCrkWwl8Oh9yEcFe2V7ZSHQgpmk/zH/ ts0w== 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=uIkVi5/18BrXAFhDrVTXIWex0kk8NMAn2RkTWk0CSSY=; b=SxOMa7sP46dgGlZJmJLfNZ0EQm0RlMjLU3TWfVNB6Ih6s2qMzzezJkNMF6g8cl0utu BHSp2/Wkj98heSUKt12gYmgHnAyucOxWSj1PYTsfpERZqxJh4QZpF5YFVPMzLxuF1rFk qGJwccRg5wtPQOzUgLLgirUUyp3wywGAhnub2Gg35/URS3j/1PNVHZxkf143KMgQgGgc frYNJRm2093EoWMI1AToLDA1QG6Ttmos27MDKBXjfrk2Fgo+RwqmNIdB9BMiUFckJeAU K1rK8iLtdPC1N5kSemmZJ9xBNuz9HWwskJ3oJW17Q7qMknEhefSv/1SRfjaRp/64wQhT oEwQ== X-Gm-Message-State: APjAAAVWUD0KmguwZcrQuvYyM1T2uoQyFaWV6PvTxASwPoC8QuQTWZ8+ f03et+cqRyyf4kZEY5PWhYKxHw== X-Google-Smtp-Source: APXvYqz7a/YBmpU2KpRRbYHzpssvbNtNYLKoplHj5DlHRkIHmGTqw52wuPetVnUrdiiuBUzJdi0dNg== X-Received: by 2002:a17:902:34a:: with SMTP id 68mr6912460pld.250.1579390568189; Sat, 18 Jan 2020 15:36:08 -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 w5sm11953694pjt.32.2020.01.18.15.36.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Jan 2020 15:36:07 -0800 (PST) Date: Sat, 18 Jan 2020 15:36:06 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Andrew Morton cc: Wei Yang , hannes@cmpxchg.org, mhocko@kernel.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: <20200118145421.0ab96d5d9bea21a3339d52fe@linux-foundation.org> Message-ID: References: <20200117233836.3434-1-richardw.yang@linux.intel.com> <20200118145421.0ab96d5d9bea21a3339d52fe@linux-foundation.org> 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 Sat, 18 Jan 2020, Andrew Morton wrote: > On Sat, 18 Jan 2020 07:38:36 +0800 Wei Yang wrote: > > > If compound is true, this means it is a PMD mapped THP. Which implies > > the page is not linked to any defer list. So the first code chunk will > > not be executed. > > > > Also with this reason, it would not be proper to add this page to a > > defer list. So the second code chunk is not correct. > > > > Based on this, we should remove the defer list related code. > > > > Fixes: 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware") > > > > Signed-off-by: Wei Yang > > Suggested-by: Kirill A. Shutemov > > Cc: [5.4+] > > This patch is identical to "mm: thp: grab the lock before manipulating > defer list", which is rather confusing. Please let people know when > this sort of thing is done. > > The earlier changelog mentioned a possible race condition. This > changelog does not. In fact this changelog fails to provide any > description of any userspace-visible runtime effects of the bug. > Please send along such a description for inclusion, as always. > The locking concern that Wei was originally looking at is no longer an issue because we determined that the code in question could simply be removed. I think the following can be added to the changelog: ----->o----- When migrating memcg charges of thp memory, there are two possibilities: (1) The underlying compound page is mapped by a pmd and thus does is not on a deferred split queue (it's mapped), or (2) The compound page is not mapped by a pmd and is awaiting split on a deferred split queue. The current charge migration implementation does *not* migrate charges for thp memory on the deferred split queue, it only migrates charges for pages that are mapped by a pmd. Thus, to migrate charges, the underlying compound page cannot be on a deferred split queue; no list manipulation needs to be done in mem_cgroup_move_account(). With the current code, the underlying compound page is moved to the deferred split queue of the memcg its memory is not charged to, so susbequent reclaim will consider these pages for the wrong memcg. Remove the deferred split queue handling in mem_cgroup_move_account() entirely. ----->o----- Acked-by: David Rientjes