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 92F38C636CC for ; Fri, 3 Feb 2023 10:24:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 336C86B0073; Fri, 3 Feb 2023 05:24:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E67F6B0074; Fri, 3 Feb 2023 05:24:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AEEA6B0075; Fri, 3 Feb 2023 05:24:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0C3666B0073 for ; Fri, 3 Feb 2023 05:24:50 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D9E80160218 for ; Fri, 3 Feb 2023 10:24:49 +0000 (UTC) X-FDA: 80425597098.12.7E43D05 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf03.hostedemail.com (Postfix) with ESMTP id 3A03B20005 for ; Fri, 3 Feb 2023 10:24:46 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=OtJIdCIO; spf=none (imf03.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675419887; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cY1asauO9N6j2ftzTeNwNb4RpkVnzG8lkgCxzfn/q9Q=; b=SciAvWTP+ko9noEpm7Ph/oz0g9j9dmfhRJt/6kSFvAx3GxM+PC0tprRvmVK8Edryh+JROW 7kcRaLS5GF7CZ3JJC0iswdFQzK0bZjMy0Mk8ZP5BEVfAjlT0Ro/Uv32b/WrybKsNs6j6nY zmoZ3KZxXclFU193VsWFOdVZfIK08Bo= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=OtJIdCIO; spf=none (imf03.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675419887; a=rsa-sha256; cv=none; b=YY2ooqjx3Uqst8C5tpFFKjTD6V0U9fA/fPIAJkbLOQjhFxFQj74xrOJLsu85dUMXJ3GeGe lz9Dc9ASm9Jj851VjiJr6Mx8P2vhm6fmgLWDbmDKh8SxFgQnuknjtC4oTPhbHGPtW1GBoB +pQJlk4hLSFIKn+jGSb04DGVJ2k4DdU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=cY1asauO9N6j2ftzTeNwNb4RpkVnzG8lkgCxzfn/q9Q=; b=OtJIdCIOO37kUxdi79dcei1uA4 PAv7KA7NbJA7WO5KFgPC/NKldw7WvvSmfpaGDBEQJb49tvZGt+iahhf0WIy4HaNQOW0P9h14skvB+ i5faICwdmc/zlLPIADhWbnSHWsC4ME/IbOmakrWze5Nrr8Qf9JOWwsKsgKBHT4rsDjGvLiCA+LbCg c8jF7HKttZXW6axIB6cEsz50tq6VKsTlj7S8s+IR78+m2axbWDZwPiasq8S5+8JUTc2TJ2f/i231x sBhu3bL6ymitSpIzaZiyy+sFGGyjEEreeC2++3EMggk2p2e2JFYlkwZuI9RMbEQ7rfG7Ku3kXCl+b x8iP79Yw==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1pNtEf-005U8p-13; Fri, 03 Feb 2023 10:24:01 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id C312D3001E5; Fri, 3 Feb 2023 11:24:35 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id B4CBC2136FF23; Fri, 3 Feb 2023 11:24:35 +0100 (CET) Date: Fri, 3 Feb 2023 11:24:35 +0100 From: Peter Zijlstra To: Raghavendra K T Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ingo Molnar , Mel Gorman , Andrew Morton , David Hildenbrand , rppt@kernel.org, Bharata B Rao , Disha Talreja , Mel Gorman Subject: Re: [PATCH V2 1/3] sched/numa: Apply the scan delay to every vma instead of tasks Message-ID: References: <1aebc55030925998a3df3cafb79c5cd28b199ea8.1675159422.git.raghavendra.kt@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1aebc55030925998a3df3cafb79c5cd28b199ea8.1675159422.git.raghavendra.kt@amd.com> X-Rspamd-Queue-Id: 3A03B20005 X-Stat-Signature: fuuit1yd6u97kzjcwisdqxxgwwhok84g X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675419886-937519 X-HE-Meta: U2FsdGVkX1+ymDAsCZ8h5++lRruoYbkW/jpBhLbBBUYwoPyf3+s0IKhGafs/4OMPT5a5xclHsWlu+DNRFw0qefKJiRXOXhXw/Uh7zY8JyVZzbW6AeXqUhbSExxksxjnaRQnSyZ+IpbSvSnaqDhc1raRSzk85LFZ0pQp8JmZTxXoZczp0K/xNFDELA23+WtclCsU4h0ljqPdlkDm3ru7IQlVHqc9jUPMk8uPqiT0OxGkFqcxbRtboLkgVxtAWIOgTtRBrJz1ILQcKmmQgeOAtKYUcPyPyho95cT1jVgXx/OSkusK02XFFBnQ+uxTuGfY5D9oYgez31K39DoHYMUbDpR+IvUDKwI5nTKzbQhhY/EefhZ4YvjtxRq5W8iakWQFEXhdFe6J9jrOqUfxJw0N1zYZcDi7/eaJx9jWyorOnqcuuopZGG0SpGZteJ11invoSMFMvUpYC2HTX3bDP0e8JvfMND7wqwu+GWTuDLBgtPJyv4gmHXKbVZHY8DoGI9ZMNw5lBnF23n+ATaBHrufUm0TgaZ4Kfuwoqvpio7o98x8eahxgfXzG3G68eK762xft82ObJqYpDbKmLAKTsZBGC9ecvS/OU9t/MMptIg9z4q6oAsgrS0Ml1aHtT8ctOTh124Cn6p26nLN2luU8HLkvNW6JG1q8BGk+L50GEIkIlAVrIevaMiK8yM054wW/rbwE4wTFzKlhvC+108nnrrYHikB+vpi6t4d3xqzOFkj02xQvb9zWc6HiGMJHA61NCr6YWsSrwjVQkxCuBAcF0c2pZG30vKK5hQFEZzCInKJwLCrWZ/cU1A+J1aPWG889wN+7C37C6VS2FNARQroq/GcmjmhjCJz9E8qe6QItRKN2pa3sg1cTuvcDuEFK2glZVzWrz5WgyxuUr4TY4qYr74AN4GY/+/XBdYAsKr6bqhno6GaBSwHt6g9L9uyOn65Ago0G+l2z31LjjAOHhhQQlpmS z1Nzf7YZ +jUFV0YcIOmPGc7cDZjm38eVWsxE+T0bXyDlTZOmrv0G8kUbIPrlmJd2fs1O1L1tkwRC4Ng47DIOTcmgISwBe1mL7M1oixUAh4LWzqcZ63udSyqtL0oeq/BgvfpSi7sl//MWXfthC/TkMORFRewBo+AAaLdRlR4wxQcZDUddlyo9F783p91klmBHxrMCaE2VFNn9rR36318gZzwJEHfCFLLd/z1x9x5POWEfS54w5lUf1oEQ= 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, Feb 01, 2023 at 01:32:20PM +0530, Raghavendra K T wrote: > From: Mel Gorman > > Avoid scanning new or very short-lived VMAs. > > (Raghavendra: Add initialization in vm_area_dup()) Given this is a performance centric patch -- some sort of qualification / justification would be much appreciated. Also, perhaps explain the rationale for the actual heuristics chosen. > Signed-off-by: Mel Gorman > Signed-off-by: Raghavendra K T > --- > include/linux/mm.h | 9 +++++++++ > include/linux/mm_types.h | 7 +++++++ > kernel/fork.c | 2 ++ > kernel/sched/fair.c | 17 +++++++++++++++++ > 4 files changed, 35 insertions(+) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 974ccca609d2..74d9df1d8982 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -611,6 +611,14 @@ struct vm_operations_struct { > unsigned long addr); > }; > > +#ifdef CONFIG_NUMA_BALANCING > +#define vma_numab_init(vma) do { (vma)->numab = NULL; } while (0) > +#define vma_numab_free(vma) do { kfree((vma)->numab); } while (0) > +#else > +static inline void vma_numab_init(struct vm_area_struct *vma) {} > +static inline void vma_numab_free(struct vm_area_struct *vma) {} > +#endif /* CONFIG_NUMA_BALANCING */ I'm tripping over the inconsistency of macros and functions here. I'd suggest making both cases functions. > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > index 500e536796ca..e84f95a77321 100644 > --- a/include/linux/mm_types.h > +++ b/include/linux/mm_types.h > @@ -435,6 +435,10 @@ struct anon_vma_name { > char name[]; > }; > > +struct vma_numab { > + unsigned long next_scan; > +}; I'm not sure what a numab is; contraction of new-kebab, something else? While I appreciate short names, they'd ideally also make sense. If we cannot come up with a better one, perhaps elucidate the reader with a comment. > + > /* > * This struct describes a virtual memory area. There is one of these > * per VM-area/task. A VM area is any part of the process virtual memory > @@ -504,6 +508,9 @@ struct vm_area_struct { > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index e4a0b8bd941c..060b241ce3c5 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -3015,6 +3015,23 @@ static void task_numa_work(struct callback_head *work) > if (!vma_is_accessible(vma)) > continue; > > + /* Initialise new per-VMA NUMAB state. */ > + if (!vma->numab) { > + vma->numab = kzalloc(sizeof(struct vma_numab), GFP_KERNEL); > + if (!vma->numab) > + continue; > + > + vma->numab->next_scan = now + > + msecs_to_jiffies(sysctl_numa_balancing_scan_delay); > + } > + > + /* > + * After the first scan is complete, delay the balancing scan > + * for new VMAs. > + */ > + if (mm->numa_scan_seq && time_before(jiffies, vma->numab->next_scan)) > + continue; I think I sorta see why, but I'm thinking it would be good to include more of the why in that comment.