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 A0DA8C10F1B for ; Wed, 28 Dec 2022 02:07:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 405DD8E0002; Tue, 27 Dec 2022 21:07:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 38D7F8E0001; Tue, 27 Dec 2022 21:07:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22F008E0002; Tue, 27 Dec 2022 21:07:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1231E8E0001 for ; Tue, 27 Dec 2022 21:07:41 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E23FDA0B49 for ; Wed, 28 Dec 2022 02:07:40 +0000 (UTC) X-FDA: 80290078680.13.015C774 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf04.hostedemail.com (Postfix) with ESMTP id 1F5A240003 for ; Wed, 28 Dec 2022 02:07:37 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="VjbigV/K"; spf=pass (imf04.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672193258; a=rsa-sha256; cv=none; b=2tqOpQaVKwVazCKwGflDbS/ALkufnr+C+wxWJvnTTA49agNVi10Qu4nmyssjSmrL0wtCsp KrQ0BOd7qff9lCsYi8OpRa/lQfVWsmz1IR2Ld6kcqIiQvX3L9RID+KuYtLC4kZmZ8R/iqQ 6IEmiV+snWo29ESQpdsQZ3upsvIzGu8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="VjbigV/K"; spf=pass (imf04.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672193258; 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=ALAgOrPaB2pAxX3RCVcWeInZ8Pi2H42Bfmqv+ZWnX/Q=; b=J+Nhz/i00kXvgRbU7oC/F8uCo6mhfwyqJsmEqQNzuDDuTX7KFWH5bHWKzxfpSUBDAYepzU p5JSO9pNUI3W3g6dhtGTsQmCn0K1r+1DFJ45+NI/9f7F2KiYhVwwO+kfJbGNFyOw3l4Xm4 q4SdUZ1gZl4WGowD8xNRIQZF1mDfZoY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1672193258; x=1703729258; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=V3wchqazEs+SWdKc1GDK1234tNnHB86+EtBs1qWbCt0=; b=VjbigV/K2VEu3w3/aEqMFB9jwZxSHH+9CgpmngoQhhnSrTfWHORruu7B q8gqt0hyBvs5ALnKVZCc5QK2bSlT04BxBe/Fd0XhQwYt+ds4Hn4wgODEx kMPgV66JGkKlJphXTsOwbHaPQZ/oPl2DpxngRlLKji/5hhQup4JA5vvD/ YxgjgYHfvBPqrMcjoOUmu7UwISWYInYy1ydJcK/VOlx9k98JINjuuuM7k j+TjSMqSZIoCwCXdDKIHFcpzBGhCUMCMKtGEeBdnV444kaetS5EqxN0VO PtJMf9axUje4R7gLgz8IiRou7B5BVYhZhvaJe20pw8jwdoPhJy9DoRWN/ A==; X-IronPort-AV: E=McAfee;i="6500,9779,10573"; a="319511241" X-IronPort-AV: E=Sophos;i="5.96,280,1665471600"; d="scan'208";a="319511241" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Dec 2022 18:07:30 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10573"; a="653185315" X-IronPort-AV: E=Sophos;i="5.96,280,1665471600"; d="scan'208";a="653185315" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Dec 2022 18:07:27 -0800 From: "Huang, Ying" To: Yin Fengwei Cc: , , , , , , , , Subject: Re: [RFC PATCH] mm/thp: check and bail out if page in deferred queue already In-Reply-To: <20221223135207.2275317-1-fengwei.yin@intel.com> (Yin Fengwei's message of "Fri, 23 Dec 2022 21:52:07 +0800") References: <20221223135207.2275317-1-fengwei.yin@intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Wed, 28 Dec 2022 10:06:19 +0800 Message-ID: <87ilhwxox0.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1F5A240003 X-Stat-Signature: 7yri4epyzuif5m918hw9hi53knj8r6kk X-HE-Tag: 1672193257-777375 X-HE-Meta: U2FsdGVkX1/2rl30nAh3dvhIJmFpUYXEucmLU8inMVMqn711bUtWZ7pK1rzsiItua+4oqyhp5dBkNg8ZCSBHEUGoGTmHkjovx+7guCyLSglU1BNKmMoBBqdCG/8SGlBaCQlGICgz4qs/72INfRWQD591JrF4Z7OnzhuihJhcSe1EKo5NvGm0VBMjOpdYSnvbYE+1UpumUeFLpsjeCTOtUtsskZx6DMmnHA1xZ7iMdB1Ql5lQuQSr7g8+bgl1e4jAxUOsA8k8w3iR4CpGleRnzqEnBtj03SAvMQdHsMNYhWrL3yIbL8Rk23cq8AzdVa0EBbb+W3FazmfbM3GA1qdlOfz81J83Ep8lIcYrNjevT5mnR9zvMjzlqww+Ax1NKGa7tvc+Dsn+QNp3XJWoJRAr/ch23lvI7aMqUOxmXKTsAyu9Ooz7ERS0pY3CBeEbDz5VpHlavclTZ59Ts7P2/5MGPaw+NWqxEdx2rt6LZP8RAePRIjkBg6GhGCpJlw4OoHQTSf4oVhXW+4E8Fa9ULuB+tjh2FKVfW74Fi5YkGYrlRw8jXsM3uVq5zCEnzttGGbUmlxPTXCHPMwkZPhmf1NfVi/8jErOnjfB+SC3NLwAi4FmWAMHasFF0XUH55pA1wAX/pUWpKAxzw1sOJNJAzuay/YlR6BssHR1zA9yc5wRohHBuJN2R6YbYBmBc2IctE94O5NQrrsUMaeR16DexM/ij8kPs6xKoAj+m87LB6qzSQRIsZv6OT4HTaCPAU7k9zUhDJBaSH9EC4r2EOy1VS+R+OdNFSdzNX9cp9LVxJDMiH++m+cg/2YWpLnx0gElzahRqZyJSyu2PW/TQVbD9ThJSRsj8+iLxveCpq+ke87RYLv8= 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: Yin Fengwei writes: > Kernel build regression with LLVM was reported here: > https://lore.kernel.org/all/Y1GCYXGtEVZbcv%2F5@dev-arch.thelio-3990X/ > with commit f35b5d7d676e ("mm: align larger anonymous mappings on THP > boundaries"). And the commit f35b5d7d676e was reverted. > > It turned out the regression is related with madvise(MADV_DONTNEED) > was used by ld.lld. But with none PMD_SIZE aligned parameter len. > trace-bpfcc captured: > 531607 531732 ld.lld do_madvise.part.0 start: 0x7feca9000000, len: 0x7fb000, behavior: 0x4 > 531607 531793 ld.lld do_madvise.part.0 start: 0x7fec86a00000, len: 0x7fb000, behavior: 0x4 > > If the underneath physical page is THP, the madvise(MADV_DONTNNED) can > trigger split_queue_lock contention raised significantly. perf showed > following data: > 14.85% 0.00% ld.lld [kernel.kallsyms] [k] > entry_SYSCALL_64_after_hwframe > 11.52% > entry_SYSCALL_64_after_hwframe > do_syscall_64 > __x64_sys_madvise > do_madvise.part.0 > zap_page_range > unmap_single_vma > unmap_page_range > page_remove_rmap > deferred_split_huge_page > __lock_text_start > native_queued_spin_lock_slowpath > > If THP can't be removed from rmap as whole THP, partial THP will be > removed from rmap by removing sub-pages from rmap. Even the THP > head page is added to deferred queue already, the split_queue_lock > will be acquired and check whether the THP head page is in the queue > already. Thus, the contention of split_queue_lock is raised. > > Before acquire split_queue_lock, check and bail out early if the THP > head page is in the queue already. The checking without holding > split_queue_lock could race with deferred_split_scan, but it doesn't > impact the correctness here. > > Test result of building kernel with ld.lld: > commit 7b5a0b664ebe (parent commit of f35b5d7d676e): > time -f "\t%E real,\t%U user,\t%S sys" make LD=ld.lld -skj96 allmodconfig all > 6:07.99 real, 26367.77 user, 5063.35 sys > > commit f35b5d7d676e: > time -f "\t%E real,\t%U user,\t%S sys" make LD=ld.lld -skj96 allmodconfig all > 7:22.15 real, 26235.03 user, 12504.55 sys > > commit f35b5d7d676e with the fixing patch: > time -f "\t%E real,\t%U user,\t%S sys" make LD=ld.lld -skj96 allmodconfig all > 6:08.49 real, 26520.15 user, 5047.91 sys > > Signed-off-by: Yin Fengwei Thank you for fixing. Reviewed-by: "Huang, Ying" > --- > My first thought was to change the per node deferred queue to per cpu. > It's complicated and may be overkill. > > For the race without lock acquired, I didn't see obvious issue here. But I > could miss something here. Let me know if I did. Thanks. > > > mm/huge_memory.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index abe6cfd92ffa..7cde9f702e63 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2837,6 +2837,9 @@ void deferred_split_huge_page(struct page *page) > if (PageSwapCache(page)) > return; > > + if (!list_empty(page_deferred_list(page))) > + return; > + > spin_lock_irqsave(&ds_queue->split_queue_lock, flags); > if (list_empty(page_deferred_list(page))) { > count_vm_event(THP_DEFERRED_SPLIT_PAGE); > > base-commit: 8395ae05cb5a2e31d36106e8c85efa11cda849be