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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C75BC433EF for ; Wed, 27 Apr 2022 20:48:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 96BC66B0073; Wed, 27 Apr 2022 16:48:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91B796B0074; Wed, 27 Apr 2022 16:48:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E3776B0075; Wed, 27 Apr 2022 16:48:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 71B106B0073 for ; Wed, 27 Apr 2022 16:48:46 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5983F28923 for ; Wed, 27 Apr 2022 20:48:46 +0000 (UTC) X-FDA: 79403847852.27.43C19AB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id E3CA014005D for ; Wed, 27 Apr 2022 20:48:39 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0002E61D2E; Wed, 27 Apr 2022 20:48:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3DFFEC385A7; Wed, 27 Apr 2022 20:48:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1651092524; bh=8SaRoR3ysXvyQTRc6V4t38Ura/+4OgWqk8Q5dIGAVSg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=uGblpJngQTrV9F4jH6x3xSZXkXdrSknRMapcn4OP+nfIzHv2Q1DUl7yR5p4he7N9W h4HAUS2tbG6eIDzHoKwqw5J2MQIa4TovvI5nhXrVVNCmUIVLwfSvd2LgGLrHjrBqbe U5/WyXOpUMvlPH1vsnyNOMLdwJDReETxH8qMqlEs= Date: Wed, 27 Apr 2022 13:48:43 -0700 From: Andrew Morton To: Bibo Mao Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Hildenbrand , Yang Shi Subject: Re: [PATCH v3] mm/khugepaged: sched to numa node when collapse huge page Message-Id: <20220427134843.576f0a18bea28de9e798004a@linux-foundation.org> In-Reply-To: <20220317065024.2635069-1-maobibo@loongson.cn> References: <20220317065024.2635069-1-maobibo@loongson.cn> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=uGblpJng; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E3CA014005D X-Stat-Signature: z3kgnxgxh6z91ac1mwzm64i1m9yqjhot X-HE-Tag: 1651092519-252440 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 Thu, 17 Mar 2022 02:50:24 -0400 Bibo Mao wrote: > collapse huge page will copy huge page from general small pages, > dest node is calculated from most one of source pages, however > THP daemon is not scheduled on dest node. The performance may be > poor since huge page copying across nodes, also cache is not used > for target node. With this patch, khugepaged daemon switches to > the same numa node with huge page. It saves copying time and makes > use of local cache better. > > With this patch, specint 2006 base performance is improved with 6% > on Loongson 3C5000L platform with 32 cores and 8 numa nodes. > Are there any acks for this one please? > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -1066,6 +1066,7 @@ static void collapse_huge_page(struct mm_struct *mm, > struct vm_area_struct *vma; > struct mmu_notifier_range range; > gfp_t gfp; > + const struct cpumask *cpumask; > > VM_BUG_ON(address & ~HPAGE_PMD_MASK); > > @@ -1079,6 +1080,13 @@ static void collapse_huge_page(struct mm_struct *mm, > * that. We will recheck the vma after taking it again in write mode. > */ > mmap_read_unlock(mm); > + > + /* sched to specified node before huage page memory copy */ > + if (task_node(current) != node) { > + cpumask = cpumask_of_node(node); > + if (!cpumask_empty(cpumask)) > + set_cpus_allowed_ptr(current, cpumask); > + } > new_page = khugepaged_alloc_page(hpage, gfp, node); > if (!new_page) { > result = SCAN_ALLOC_HUGE_PAGE_FAIL; > -- > 2.31.1 >