From: "Dmitry Adamushko" <dmitry.adamushko@gmail.com>
To: "Mike Galbraith" <efault@gmx.de>
Cc: "Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: SD scheduler testing hitch
Date: Mon, 9 Apr 2007 11:20:16 +0200 [thread overview]
Message-ID: <b647ffbd0704090220p60c49ec9w8eb1083943526155@mail.gmail.com> (raw)
In-Reply-To: <1176099797.6355.122.camel@Homer.simpson.net>
On 09/04/07, Mike Galbraith <efault@gmx.de> wrote:
> On Sun, 2007-04-08 at 21:34 +0300, Al Boldi wrote:
> > Mike Galbraith wrote:
> > > On Sat, 2007-04-07 at 19:17 +0200, Mike Galbraith wrote:
> > > > I lowered the time to 500us, and ran at nice -10.. it starves tenpercent
> > > > here every time. (ran as taskset -c 1 nice -n -10 ./fairtest) The
> > > > starving 10% duty cycle task has trouble getting 1% CPU.
> > >
> > > Hmm. Playing with it some more today, it still happens, but it's not
> > > very repeatable. Something is odd. I wonder if any SD using readers
> > > will try it.
> >
> > Tried it on mainline 2.6.20.3.
> > It's not easily repeatable, but it's got the same problem.
In my case, it's easily reproducible. Below is a mainline 2.6.19.
Look at both %CPU and TIME+ (sched_time).
top - 10:55:00 up 33 min, 8 users, load average: 1.07, 0.61, 0.51
Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie
Cpu(s): 76.0% us, 0.3% sy, 0.0% ni, 23.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 256592k total, 251888k used, 4704k free, 46516k buffers
Swap: 272120k total, 4924k used, 267196k free, 90048k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8113 dimm 15 0 1460 436 360 R 74.4 0.2 1:43.63 fairtest_xx
8114 dimm 15 0 1460 108 32 S 0.3 0.0 0:00.15 fairtest_xx
If you take a look at my previous report, you'll also notice
"strangeness" with both cpu% and sched_time.
sched_clock() is based on "tsc" and it's available for my CPU. So
maybe something fishy is going on with accounting.
I just wonder, why it's so easily reproducible in my case for both
mainline and SD (besides a 2.6.13 mainline, but I have to re-run all
the tests letting tenp run longer for the "sched_time" to be
accumulated)...
--
Best regards,
Dmitry Adamushko
next prev parent reply other threads:[~2007-04-09 9:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-08 18:34 Al Boldi
2007-04-09 6:23 ` Mike Galbraith
2007-04-09 9:20 ` Dmitry Adamushko [this message]
2007-04-09 9:57 ` Mike Galbraith
-- strict thread matches above, loose matches on Subject: below --
2007-04-04 14:04 [sched] redundant reschedule when set_user_nice() boosts a prio of a task from the "expired" array Dmitry Adamushko
2007-04-04 14:15 ` Ingo Molnar
2007-04-04 20:05 ` [PATCH] " Dmitry Adamushko
2007-04-07 0:03 ` Andrew Morton
2007-04-07 9:24 ` Ingo Molnar
2007-04-07 16:20 ` SD scheduler testing hitch Mike Galbraith
2007-04-07 17:17 ` Mike Galbraith
2007-04-08 8:02 ` Mike Galbraith
2007-04-09 0:14 ` Dmitry Adamushko
2007-04-09 0:23 ` Dmitry Adamushko
2007-04-09 5:54 ` Mike Galbraith
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=b647ffbd0704090220p60c49ec9w8eb1083943526155@mail.gmail.com \
--to=dmitry.adamushko@gmail.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome