Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp8570843ybl; Thu, 16 Jan 2020 19:53:24 -0800 (PST) X-Google-Smtp-Source: APXvYqz+Y14sCDrQT9evvaG9ybUP2uTQFuNjAXdZDwy15CuJqwVS6cFqcUsq/47sCPfOiGAMzitM X-Received: by 2002:a9d:6b91:: with SMTP id b17mr4751759otq.321.1579233204527; Thu, 16 Jan 2020 19:53:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579233204; cv=none; d=google.com; s=arc-20160816; b=GVZfNBSwMZMSsRsISmpIfyQ4LSqKZVveF1PX97+DDetDGpoaBAKlk84sYCn+0vGUAG iUczgwfnLCHtXyURlk7kFBYwDk4rGCjMh9iducctC5HjlqeQ9TbkWnVBByJ2iBpCAkd1 fBLDc6K6DMBDnqcLVF6x3xUeQ+zUWLhn3Eie7Eiy41WCLmuqtnGo9gxy9QemmF0CiWUR qZUU0emc9qazbn4cZakvQJ1hbRhg1uPA8M+4/ygYuE1JtKRjwAjKiBYGlSp2bzB2cGxX FKW4YP+m6v6YigdvOBM7BuBhJJd/NBjIJdz8sOhaWxPXcxGy8nvC0B+OsvI4eb4it0Z7 Kt7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date; bh=yGSBNBoBVBixgK2yicQ2rmnqjjLfMyI5Y7cLwaspyMg=; b=hUt45iMBoIfkuda9Jlhpa6572sohiQgmb9ie00DPVeNa/GcWqVkj/gET/X2RN01GNz azXhsKrKKZzYrC6WO1V0iApxlkaO/DQ90/GYGLeil0gcu2zw5gGfDpstJt/5gK0qO7Hb GCtXULYefYyP8axneTzBPjOlPXTLnGvLcbHkKnzbtUeLi85k8AAgMrShQUpYcg9uSmGq nX5go1eBBwEYzZvLyS81HJJNYtLqTEkht1P8qi5XifDTcp6dgggBl5GrwobZZdK76LUo zjPLyAknIUKdbZ+6zIn6kTdbUeTvFb+2iQc9BbFYhFnnApbiFO7hyIH+nco7G2pUKDUG iNXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d22si15040557oti.316.2020.01.16.19.53.10; Thu, 16 Jan 2020 19:53:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733138AbgAQAr3 (ORCPT + 99 others); Thu, 16 Jan 2020 19:47:29 -0500 Received: from mga07.intel.com ([134.134.136.100]:37145 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726378AbgAQAr3 (ORCPT ); Thu, 16 Jan 2020 19:47:29 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2020 16:47:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,327,1574150400"; d="scan'208";a="306066002" Received: from unknown (HELO localhost) ([10.239.159.54]) by orsmga001.jf.intel.com with ESMTP; 16 Jan 2020 16:47:24 -0800 Date: Fri, 17 Jan 2020 08:47:35 +0800 From: Wei Yang To: David Rientjes Cc: Kirill Tkhai , Wei Yang , hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, 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 v3] mm: thp: grab the lock before manipulation defer list Message-ID: <20200117004735.GA16207@richard> Reply-To: Wei Yang References: <20200116013100.7679-1-richardw.yang@linux.intel.com> <0bb34c4a-97c7-0b3c-cf43-8af6cf9c4396@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 16, 2020 at 02:01:59PM -0800, David Rientjes wrote: >On Thu, 16 Jan 2020, Kirill Tkhai wrote: > >> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> > index c5b5f74cfd4d..6450bbe394e2 100644 >> > --- a/mm/memcontrol.c >> > +++ b/mm/memcontrol.c >> > @@ -5360,10 +5360,12 @@ static int mem_cgroup_move_account(struct page *page, >> > } >> > >> > #ifdef CONFIG_TRANSPARENT_HUGEPAGE >> > - if (compound && !list_empty(page_deferred_list(page))) { >> > + if (compound) { >> > spin_lock(&from->deferred_split_queue.split_queue_lock); >> > - list_del_init(page_deferred_list(page)); >> > - from->deferred_split_queue.split_queue_len--; >> > + if (!list_empty(page_deferred_list(page))) { >> > + list_del_init(page_deferred_list(page)); >> > + from->deferred_split_queue.split_queue_len--; >> > + } >> > spin_unlock(&from->deferred_split_queue.split_queue_lock); >> > } >> > #endif >> > @@ -5377,11 +5379,13 @@ static int mem_cgroup_move_account(struct page *page, >> > page->mem_cgroup = to; >> > >> > #ifdef CONFIG_TRANSPARENT_HUGEPAGE >> > - if (compound && list_empty(page_deferred_list(page))) { >> > + if (compound) { >> > spin_lock(&to->deferred_split_queue.split_queue_lock); >> > - list_add_tail(page_deferred_list(page), >> > - &to->deferred_split_queue.split_queue); >> > - to->deferred_split_queue.split_queue_len++; >> > + if (list_empty(page_deferred_list(page))) { >> > + list_add_tail(page_deferred_list(page), >> > + &to->deferred_split_queue.split_queue); >> > + to->deferred_split_queue.split_queue_len++; >> > + } >> > spin_unlock(&to->deferred_split_queue.split_queue_lock); >> > } >> > #endif >> >> The patch looks OK for me. But there is another question. I forget, why we unconditionally >> add a page with empty deferred list to deferred_split_queue. Shouldn't we also check that >> it was initially in the list? Something like: >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index d4394ae4e5be..0be0136adaa6 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -5289,6 +5289,7 @@ static int mem_cgroup_move_account(struct page *page, >> struct pglist_data *pgdat; >> unsigned long flags; >> unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1; >> + bool split = false; >> int ret; >> bool anon; >> >> @@ -5346,6 +5347,7 @@ static int mem_cgroup_move_account(struct page *page, >> if (!list_empty(page_deferred_list(page))) { >> list_del_init(page_deferred_list(page)); >> from->deferred_split_queue.split_queue_len--; >> + split = true; >> } >> spin_unlock(&from->deferred_split_queue.split_queue_lock); >> } >> @@ -5360,7 +5362,7 @@ static int mem_cgroup_move_account(struct page *page, >> page->mem_cgroup = to; >> >> #ifdef CONFIG_TRANSPARENT_HUGEPAGE >> - if (compound) { >> + if (compound && split) { >> spin_lock(&to->deferred_split_queue.split_queue_lock); >> if (list_empty(page_deferred_list(page))) { >> list_add_tail(page_deferred_list(page), >> > >I think that's a good point, especially considering that the current code >appears to unconditionally place any compound page on the deferred split >queue of the destination memcg. The correct list that it should appear >on, I believe, depends on whether the pmd has been split for the process >being moved: note the MC_TARGET_PAGE caveat in >mem_cgroup_move_charge_pte_range() that does not move the charge for >compound pages with split pmds. So when mem_cgroup_move_account() is >called with compound == true, we're moving the charge of the entire >compound page: why would it appear on that memcg's deferred split queue? Well, Kirill's change is easy to understand, while your statement here is a bit hard for me. Seems I lack some knowledge about cgroup. I am sorry about this. :-( -- Wei Yang Help you, Help me