From: Frederic Weisbecker <frederic@kernel.org>
To: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Michal Hocko <mhocko@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Valentin Schneider <vschneid@redhat.com>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org
Subject: Re: [PATCH 4/6] tick/nohz: Move nohz_full related fields out of hot task struct's places
Date: Tue, 1 Jul 2025 14:17:42 +0200 [thread overview]
Message-ID: <aGPR5srdOX8UWakS@localhost.localdomain> (raw)
In-Reply-To: <cd6d72c7-cdc7-4af6-b070-076f64887ee7@linux.ibm.com>
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 <frederic@kernel.org>
> > ---
> > 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
next prev parent reply other threads:[~2025-07-01 12:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 15:23 [PATCH 0/6 v3] sched/mm: LRU drain flush on nohz_full Frederic Weisbecker
2025-04-10 15:23 ` [PATCH 1/6] task_work: Provide means to check if a work is queued Frederic Weisbecker
2025-04-10 15:23 ` [PATCH 2/6] sched/fair: Use task_work_queued() on numa_work Frederic Weisbecker
2025-04-10 15:23 ` [PATCH 3/6] sched: Use task_work_queued() on cid_work Frederic Weisbecker
2025-04-10 15:23 ` [PATCH 4/6] tick/nohz: Move nohz_full related fields out of hot task struct's places Frederic Weisbecker
2025-04-23 18:40 ` Shrikanth Hegde
2025-07-01 12:17 ` Frederic Weisbecker [this message]
2025-04-10 15:23 ` [PATCH 5/6] sched/isolation: Introduce isolated task work Frederic Weisbecker
2025-04-11 10:25 ` Oleg Nesterov
2025-04-11 22:00 ` Frederic Weisbecker
2025-04-12 5:12 ` K Prateek Nayak
2025-04-10 15:23 ` [PATCH 6/6] mm: Drain LRUs upon resume to userspace on nohz_full CPUs Frederic Weisbecker
[not found] ` <20250412025831.4010-1-hdanton@sina.com>
2025-07-01 12:36 ` [PATCH 0/6 v3] sched/mm: LRU drain flush on nohz_full Frederic Weisbecker
2025-07-02 11:54 ` Hillf Danton
-- strict thread matches above, loose matches on Subject: below --
2025-07-03 14:07 [PATCH 0/6 v4] " Frederic Weisbecker
2025-07-03 14:07 ` [PATCH 4/6] tick/nohz: Move nohz_full related fields out of hot task struct's places Frederic Weisbecker
2025-07-17 16:32 ` Valentin Schneider
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aGPR5srdOX8UWakS@localhost.localdomain \
--to=frederic@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=sshegde@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.