From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Ken Chen <kenchen@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] sched: schedstat needs a diet
Date: Thu, 18 Oct 2007 19:13:05 -0400 [thread overview]
Message-ID: <20071018231305.GA3035@Krystal> (raw)
In-Reply-To: <b040c32a0710181557x4741b9ddxeb01edc788defb6@mail.gmail.com>
* Ken Chen (kenchen@google.com) wrote:
> On 10/18/07, Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> > Good question indeed. How large is this memory footprint exactly ? If it
> > is as small as you say, I suspect that the real issue could be that
> > these variable are accessed by the scheduler critical paths and
> > therefore trash the caches.
>
> Maybe my wording was ambiguous, I meant to reduce cache line pollution
> when accessing these schedstat fields.
>
> With unsigned long, on x86_64, schedstat consumes 288 bytes for each
> sched_domain and 128 bytes in struct rq. On a extremely small system
> that has a couple of CPU sockets with one level of numa node, there
> will be 704 bytes per CPU for schedstat. Given the sparseness of
> them, we are probably talking about 11-12 cache line eviction on
> several heavily used scheduler functions. Reduce cache line pollution
> is the primary goal, actual memory consumption isn't really a concern.
>
Generally speaking, if such cache trashing is an issue, why don't we
make sure that each task struct member is declared in this structure
following its access frequency ? (except for #ifdef blocks, which should
stay together) It could then statistically save a lot of cachelines.
Or is it already the case ? It doesn't look like it when I see:
struct list_head ptrace_list;
Just beside the
struct mm_struct *mm, *active_mm;
pointers.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2007-10-18 23:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-16 20:37 [patch] sched: schedstat needs a diet Ken Chen
2007-10-17 7:23 ` Ingo Molnar
2007-10-17 9:29 ` Peter Zijlstra
2007-10-18 22:19 ` Mathieu Desnoyers
2007-10-18 22:57 ` Ken Chen
2007-10-18 23:13 ` Mathieu Desnoyers [this message]
2007-10-31 9:06 ` Rick Lindsley
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=20071018231305.GA3035@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=kenchen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/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.