From: Ingo Molnar <mingo@elte.hu>
To: "Zhang, Yanmin" <yanmin.zhang@intel.com>
Cc: a.p.zijlstra@chello.nl,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: scale sysctl_sched_shares_ratelimit with nr_cpus
Date: Mon, 18 Aug 2008 10:42:01 +0200 [thread overview]
Message-ID: <20080818084201.GA25432@elte.hu> (raw)
In-Reply-To: <37E52D09333DE2469A03574C88DBF40F024EBE06@pdsmsx414.ccr.corp.intel.com>
* Zhang, Yanmin <yanmin.zhang@intel.com> wrote:
> >>Does a scheduler trace show anything about why that drop happens? Do
> >>something like this to trace the scheduler:
> >>
> >>assuming debugfs is mounted under /debug and CONFIG_SCHED_TRACER=y:
> >>
> >> echo 1 > /debug/tracing/tracing_cpumask
> >> echo sched_switch > /debug/tracing/available_tracers
> >> cat /debug/tracing/trace_pipe > trace.txt
> [YM] Thanks for your good pointer. I collected the data and didn't find
> anything abnormal except the pid about waker.
>
> Receiver-197-13665 [00] 1369.966423: 13665:120:R + 13607:120:S
> Receiver-197-13665 [00] 1369.966440: 13665:120:R + 13611:120:S
> Receiver-197-13665 [00] 1369.966458: 13665:120:R + 13615:120:S
> Receiver-197-13665 [00] 1369.966463: 13665:120:R + 13619:120:S
> Receiver-197-13665 [00] 1369.966466: 13665:120:R + 13623:120:S
> Receiver-197-13665 [00] 1369.966469: 13665:120:R + 13627:120:S
> Receiver-197-13665 [00] 1369.966475: 13665:120:R + 13631:120:S
> Receiver-197-13665 [00] 1369.966480: 13665:120:R + 13635:120:S
> Receiver-197-13665 [00] 1369.966485: 13665:120:R + 13639:120:S
> Receiver-197-13665 [00] 1369.966495: 13665:120:R + 13643:120:S
> Receiver-197-13665 [00] 1369.966507: 13871:120:R + 13647:120:S
> Above waker pid is 13871 while the current pid is 13665. I found lots of
> such mismatch data.
>
> Receiver-197-13665 [00] 1369.966513: 13465:120:R + 13651:120:S
> Receiver-197-13665 [00] 1369.966516: 13665:120:R + 13655:120:S
> Receiver-197-13665 [00] 1369.966521: 13665:120:R + 13659:120:S
> Receiver-197-13665 [00] 1369.966530: 13665:120:R + 13667:120:S
> Receiver-197-13665 [00] 1369.966544: 13883:120:R + 13663:120:S
> Receiver-197-13665 [00] 1369.966549: 13665:120:R ==> 13667:120:R
> Sender-140-13667 [00] 1369.966573: 13351:120:R + 13668:120:S
> Sender-140-13667 [00] 1369.966578: 13667:120:R ==> 13659:120:R
>
>
> BTW, I analyzed schedstat data and found wake_affine and
> load_balance_newidle seem abnormal. 2.6.27-rc has more task pulls. I
> set CONFIG_GROUP_SCHED=n with above testing.
hm, does this mean there's too much idle time during the testrun,
because we dont load-balance agressively enough?
Ingo
next prev parent reply other threads:[~2008-08-18 8:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <37E52D09333DE2469A03574C88DBF40F024EBD2F@pdsmsx414.ccr.corp.intel.com>
2008-08-18 6:52 ` scale sysctl_sched_shares_ratelimit with nr_cpus Ingo Molnar
2008-08-18 6:54 ` Zhang, Yanmin
2008-08-18 7:01 ` Ingo Molnar
2008-08-18 8:26 ` Zhang, Yanmin
2008-08-18 8:42 ` Ingo Molnar [this message]
2008-08-18 8:45 ` Zhang, Yanmin
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=20080818084201.GA25432@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=yanmin.zhang@intel.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.