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 000F0C83038 for ; Tue, 1 Jul 2025 12:17:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B39E6B00A1; Tue, 1 Jul 2025 08:17:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 964A16B00A4; Tue, 1 Jul 2025 08:17:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8536E6B00A2; Tue, 1 Jul 2025 08:17:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 753186B009F for ; Tue, 1 Jul 2025 08:17:48 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 45D1F1D70FD for ; Tue, 1 Jul 2025 12:17:48 +0000 (UTC) X-FDA: 83615597016.28.CAA983B Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf13.hostedemail.com (Postfix) with ESMTP id A684620018 for ; Tue, 1 Jul 2025 12:17:46 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=j9dHqDUu; spf=pass (imf13.hostedemail.com: domain of frederic@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=frederic@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751372266; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oU/L5JZZWZ8oceGYi9teJMfpjJEdF5GGLJkY/V11lec=; b=zA4DONdPRyEXCmtLaUyYUgBqEWJZPN4pIdaFrTSkkKuuU17VchSYPfL/G4tP3haGu5QVmh BGZItAEt5Af2ncNr38Vf9aFThXu7Ictp91h5IRZK6zeyQu/3upW5sOGw0ouxwT+ZP/emIl gqFPlEjW9ydkkhe4gPsyTHLa6HMKzQQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=j9dHqDUu; spf=pass (imf13.hostedemail.com: domain of frederic@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=frederic@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751372266; a=rsa-sha256; cv=none; b=U7JzQJ2GCnnLe0htea+FK4bdXJQ7oQZzkaYP7dweLoy323rzNUZkmgVJCJUa1diOYO/011 ZzFb7Gd2odQ33P+OUlVC5LclsfwTNiEjn3luMk0XIiUP5x5xtaept+37Qpv0sXaqKFYK97 BqdKdm+ykcGAvj3RWk8VwX4/QxApKS4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id EACBCA52F46; Tue, 1 Jul 2025 12:17:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 201CBC4CEEB; Tue, 1 Jul 2025 12:17:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751372265; bh=wYk9AylY09l8uNGrSbHX4zHJJrhd4ZCoh4vmrv5C+yk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=j9dHqDUuFXoCVwqI0YMxOssOe9e0EytYKobmLZerE6qLZSotIufSHY0BMRuaN+RCm 3NSPZIhccwqUjUltprtiGRR79Jof+bTYUcMti+GCiGxFiJGOpcse0NpWOp2uHn9TkX dKZCdVdwKv8pCcab2WprAF8bRpTcQZ8SKkTlalbXf1sHng8KW59mwCKHABaN3/x6EL YkexOiUfruzLMztOhsKtQzIeLiiPLQdjhKxih55ufbMEv6py4C1FKHDSXIWmoW6Bin 7zFtxCvXUtvK/wti+bI5eTfseJDSHarq4IseZ1tNNwbi7n4+R2SsOuv9akGLVzqtjK eaCChCEo4V3PA== Date: Tue, 1 Jul 2025 14:17:42 +0200 From: Frederic Weisbecker To: Shrikanth Hegde Cc: LKML , Andrew Morton , Ingo Molnar , Marcelo Tosatti , Michal Hocko , Oleg Nesterov , Peter Zijlstra , Thomas Gleixner , Valentin Schneider , Vlastimil Babka , linux-mm@kvack.org Subject: Re: [PATCH 4/6] tick/nohz: Move nohz_full related fields out of hot task struct's places Message-ID: References: <20250410152327.24504-1-frederic@kernel.org> <20250410152327.24504-5-frederic@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A684620018 X-Stat-Signature: fcf5ntfwq8b5mhi5ne9s1pbw7kkghz6f X-HE-Tag: 1751372266-898654 X-HE-Meta: U2FsdGVkX19kfZDFgxFrP3FPuQuriTPrLu8QZYMBLDbB1KBLLaffEIut7wOHNA1aj1zRKIJvBIq3MW6B2VaKjVV6tHh+3j2O5KxcZpih6fu+RxTSMkgCVqbHhKBqisw9gYt1nKDj7qWDLWCYb12bV9+jmqPS96QQpOYC9YoTeWtGPPnXtn3Cmttc/1dmiimlm/wNjDnm+yc9LDRjV5ORkzleG86fcE9RKcVCoZN+kaw9hVx+nV8uWlLlkvWmxKC/MBHIwaUOwyNbtjdbWkmPYCDn44GzAyaIsaedBuby6JRluvgHcrCQG0cAmMJ45tBisJGAHf+g5JqvzdsD8bjEEqWC1cJlJNKvcHCtd/1UGb7eINI/nNVYhFyYxrWEdNoqFIOM5vJxTklQTI+VskURl45pjgt6B1AyDIme2Qq2IB4VPw+dpiAhjqdjMkTsVVn8sgImdDDa1+WhWVF7ODhHi+82PPjZR11FS4wcl49f0QP4zrvJvXmWWZPFZqRn5vlmVWjUWpfoCGdkKyox0eF+4jbxqwDRF4xfu6yB26dNysQrTI26495a3a56VYK5OkZ0aEOfB1FufQ1ypppMdcOgvFBXz9qA+T7Pqk6j0BOF2T82HuCx+65fZ7RFsw+fB9aObUvOt3sJhFwXpajjhbXSWlfdrGmSiTVNtvdaDPcHLJP/zsoqdQcNr4XE8w9fq0QXe9oaE4P/odEvuhJ+4yaRDXXuJb6/YF/MRKMiSgwer7DmE90QQEpCi8OncGQqDSmHda69fLc5wLqdzG9vIehiTLd7rQPqECiBrrXxg1HPPsof2h2KfYA1xuWnexipTwpQFehARw5rlXkEOCtR9bYtK+3viNFPu4RX2lUzt7pvNnHg4ldXmEg06OIs00GTdU+fSYy/QPOn9ODA4Eao2BhTBu9KiJECJmDa2CEenJB9bLVF2pTwISCR8j9nyH6Nw0E194AuBZEh2kT3z1Kjn0N aSA== 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: Le Thu, Apr 24, 2025 at 12:10:26AM +0530, Shrikanth Hegde a écrit : > > > On 4/10/25 20:53, Frederic Weisbecker wrote: > > nohz_full is a feature that only fits into rare and very corner cases. > > Yet distros enable it by default and therefore the related fields are > > always reserved in the task struct. > > > > Those task fields are stored in the middle of cacheline hot places such > > as cputime accounting and context switch counting, which doesn't make > > any sense for a feature that is disabled most of the time. > > > > Move the nohz_full storage to colder places. > > > > Signed-off-by: Frederic Weisbecker > > --- > > include/linux/sched.h | 14 ++++++++------ > > 1 file changed, 8 insertions(+), 6 deletions(-) > > > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > index f96ac1982893..b5ce76db6d75 100644 > > --- a/include/linux/sched.h > > +++ b/include/linux/sched.h > > @@ -1110,13 +1110,7 @@ struct task_struct { > > #endif > > u64 gtime; > > struct prev_cputime prev_cputime; > > -#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN > > - struct vtime vtime; > > -#endif > > -#ifdef CONFIG_NO_HZ_FULL > > - atomic_t tick_dep_mask; > > -#endif > > /* Context switch counts: */ > > unsigned long nvcsw; > > unsigned long nivcsw; > > @@ -1438,6 +1432,14 @@ struct task_struct { > > struct task_delay_info *delays; > > #endif > > +#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN > > + struct vtime vtime; > > +#endif > > + > > +#ifdef CONFIG_NO_HZ_FULL > > + atomic_t tick_dep_mask; > > +#endif > > + > > #ifdef CONFIG_FAULT_INJECTION > > int make_it_fail; > > unsigned int fail_nth; > > > > Hi Frederic. > > maybe move these nohz related fields into their own cacheline instead? > > > on PowerPC where we have 128byte cache instead, i see > these fields are crossing a cache line boundary. > > without patch: > /* XXX last struct has 4 bytes of padding */ > > struct vtime vtime; /* 2360 48 */ > atomic_t tick_dep_mask; /* 2408 4 */ > /* XXX 4 bytes hole, try to pack */ > > long unsigned int nvcsw; /* 2416 8 */ > long unsigned int nivcsw; /* 2424 8 */ > /* --- cacheline 19 boundary (2432 bytes) --- */ > > > With patch: > struct vtime vtime; /* 3272 48 */ > struct callback_head nohz_full_work; /* 3320 16 */ > /* --- cacheline 26 boundary (3328 bytes) was 8 bytes ago --- */ > atomic_t tick_dep_mask; /* 3336 4 */ > It's not much a big deal because those fields shouldn't be accessed much closely in time. Also such a cache alignement is hard to maintain everywhere when there are so many ifdefferies in that structure. Thanks. -- Frederic Weisbecker SUSE Labs