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 EDBBDC4167D for ; Thu, 9 Nov 2023 14:36:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88D658D00EA; Thu, 9 Nov 2023 09:36:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 83D7E8D0073; Thu, 9 Nov 2023 09:36:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 72DA58D00EA; Thu, 9 Nov 2023 09:36:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5EFA18D0073 for ; Thu, 9 Nov 2023 09:36:18 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2C8654034F for ; Thu, 9 Nov 2023 14:36:18 +0000 (UTC) X-FDA: 81438666036.08.257B90D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf21.hostedemail.com (Postfix) with ESMTP id 69A3A1C0016 for ; Thu, 9 Nov 2023 14:36:16 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=D2rqESR3; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699540576; a=rsa-sha256; cv=none; b=JWVahLFC5xsJmjdcM3vdOG/f2yEuLJCEjC1zHN90QNB6UditXPsSXAIjGn7DarT9MNVAQQ 2CH9qGnird+sEky4NQ4fkukr5r5rSbrmPQDWK+nGrC0U2tXG0FVr83SKHbnBtvDfScuJuw 8bjnDX+fq5ZB7H1iQXSFhEoKVBuviqg= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=D2rqESR3; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699540576; 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=i/3avsOpLd3aZaWrgDNXJxmHWSlkc1l2DLIoTImK/GQ=; b=sbzMyb+bpmvL9nPHTb1U1wPOdwbxeRVUcCRzaq/X6TGVau3USTwh0gzxujlLtZ0xpvokEY rIcX+pkDsgmOntjt5sGmirRAMbaZCI+u9uCnyvfL4JNO4lfF3x3JpzDexWzaL1QcondqbS zdg98VVX9qM6IpfczY+L2oyWsZkdA9s= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=i/3avsOpLd3aZaWrgDNXJxmHWSlkc1l2DLIoTImK/GQ=; b=D2rqESR35iVv9aNRPQT5DbbQQ1 D4KlbLopXeIeEKJwD9qPXGddscAVpziQIQQ6rsk/xzyv2qmQ9kFw63qmPr7+QD/FBI+M5Oj6avYVO T9CYOu8kv75GD3JtZCQZw86DS/yxhbEMbY3UpjDowYqtUQkrFQgAp8ze+4HKjsQIYFr6gFgE+pg3e eYutrhgJBzRrmnh0eFn7nYy0rvzKj5OZkCrJ8ZBavW2bRs0k/VXoko2K3r3SYu23g4EPursgbjRPj eE80tn3FgJ1gibRs46ZOd3rd3xJ69MVwmr/8uvM2k00gv8uIzXutODSKYvmGOU/iyvNrNkePh3N4K KM52jbiA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r168X-007mgh-Ri; Thu, 09 Nov 2023 14:36:01 +0000 Date: Thu, 9 Nov 2023 14:36:01 +0000 From: Matthew Wilcox To: Byungchul Park Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, akpm@linux-foundation.org, ying.huang@intel.com, namit@vmware.com, xhao@linux.alibaba.com, mgorman@techsingularity.net, hughd@google.com, david@redhat.com, peterz@infradead.org, luto@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com Subject: Re: [v4 2/3] mm: Defer TLB flush by keeping both src and dst folios at migration Message-ID: References: <20231109045908.54996-1-byungchul@sk.com> <20231109045908.54996-3-byungchul@sk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231109045908.54996-3-byungchul@sk.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 69A3A1C0016 X-Stat-Signature: k8e1iio8gzzuro3yqozd8jfhhyhz18n7 X-Rspam-User: X-HE-Tag: 1699540576-993870 X-HE-Meta: U2FsdGVkX19Gyc17x7OdBSMT/ihlaxtmaMTx5RMFhOF8tF2R5tUO48d084eBs+ppQ0N7a8sH5ERAzOlwLMRwDXOQwTNJE1a0xWmv2UIoBv/A3zCWBw56lyz58kj7u3GYR1lg8VYyc1upgDotEwJZ4SfRmu83m9gHFeu9hhWeDdFjJape048h/nIaxc7+vzuFJd+3Kbt8YFru5LOWG3HQfKHJQbSux3eiDdFpo8C9KY+nmpRTz0XPpkHEOQIKLZpoMUuNWI637p04ijg9uyZnjjsix16rQis71pvngzm0acquLsNY6R7BwSSpZ5oV6ae7N/3hO5tdHuToOBeWW5KOH7D009+Yr3anTuT9OVSgjeySvkJsDVx+EKI2/n6emNSvpJzKlZZs1l9GEVpDYjHfX5N6NeCd0rKMks4leMHvMnE3fO2IMMKxlMb2AIpQRDcQ55iVyJMWRBStIG3Lf2eMs7UZAkhkN5Y1b0niMsR1fBuR83ENFxLObAEPNyZO723enPPDZ+MoyUsfJcrXGH0OgqSIyQnwZkRm6CINyvHYXb/WXbbt6aw2GFCQF1Zl6/Cqqh66E/U2nsZKS1R4vBnZJDf3/n8gIFJp8p+VlyND9vnUQX700gck5u7EDDM/d5xFgGM8SU1BshQnvXFoK0r0DsALQAIOcAr+f5vzIdwQd3q10f7yjwJN+lilP1HaDqHwFHjvUWUSbleGiZZF2eMd9JdF/QmHHH2SgcWzmEIQ+ZqFUsbu+fBWmdVKRtrrdqiVr0qT7hFwMkcu9fTVOImMxMlKXgHY+b3vefjeWLv8ylnoq1xVPeiC/S4/Sd2lsyPpz4pYo1G1yCUt4g1QKDl664XYwbUpjUS4UDU+N9kGj8gyeatHJ9bAaWLad+Gm9mRYpMipbqL0dQ9XLmD1wbVlvXLqWLmKgzEGR66awJG8NOtMB/+ooSeBFGdxdWE8B6zbFm79h6dsEkVUpenGY7Q aP4Fh2d+ bOvvO3Pi/ffFX7mhbgvvShfFrM3L8qghBR+ScQ7oqhzq1MCBZ/P9Y8LYHk6DMmPXylCosnYuSA6ET6dPQcaV1ewQAOv5ePNkXZJDUElvMRFj8OvWM2OcXOniCt81QYcGMAdWPJKT5iseI4Bw= 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: List-Subscribe: List-Unsubscribe: On Thu, Nov 09, 2023 at 01:59:07PM +0900, Byungchul Park wrote: > +++ b/include/linux/page-flags.h > @@ -136,6 +136,7 @@ enum pageflags { > PG_arch_2, > PG_arch_3, > #endif > + PG_migrc, /* Page is under migrc's control */ > __NR_PAGEFLAGS, Yeah; no. We're out of page flags. And CXL is insufficiently compelling to add more. If you use CXL, you don't care about performance, by definition. > @@ -589,6 +590,9 @@ TESTCLEARFLAG(Young, young, PF_ANY) > PAGEFLAG(Idle, idle, PF_ANY) > #endif > > +TESTCLEARFLAG(Migrc, migrc, PF_ANY) > +__PAGEFLAG(Migrc, migrc, PF_ANY) Why PF_ANY? > +/* > + * Initialize the page when allocated from buddy allocator. > + */ > +static inline void migrc_init_page(struct page *p) > +{ > + __ClearPageMigrc(p); > +} This flag should already be clear ... ? > +/* > + * Check if the folio is pending for TLB flush and then clear the flag. > + */ > +static inline bool migrc_unpend_if_pending(struct folio *f) > +{ > + return folio_test_clear_migrc(f); > +} If you named the flag better, you wouldn't need this wrapper. > +static void migrc_mark_pending(struct folio *fsrc, struct folio *fdst) > +{ > + folio_get(fsrc); > + __folio_set_migrc(fsrc); > + __folio_set_migrc(fdst); > +} This is almost certainly unsafe. By using the non-atomic bit ops, you stand the risk of losing a simultaneous update to any other bit in this word. Like, say, someone trying to lock the folio? > +++ b/mm/page_alloc.c > @@ -1535,6 +1535,9 @@ inline void post_alloc_hook(struct page *page, unsigned int order, > > set_page_owner(page, order, gfp_flags); > page_table_check_alloc(page, order); > + > + for (i = 0; i != 1 << order; ++i) > + migrc_init_page(page + i); No.