From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mtk.manpages@gmail.com, Juri Lelli <juri.lelli@gmail.com>,
Dario Faggioli <raistlin@linux.it>, Ingo Molnar <mingo@elte.hu>,
lkml <linux-kernel@vger.kernel.org>,
Dave Jones <davej@redhat.com>
Subject: Re: [BUG] sched_setattr() SCHED_DEADLINE hangs system
Date: Mon, 12 May 2014 08:53:59 +0200 [thread overview]
Message-ID: <53707007.3080003@gmail.com> (raw)
In-Reply-To: <536F8F0E.7020301@gmail.com>
On 05/11/2014 04:54 PM, Michael Kerrisk (man-pages) wrote:
> [Dave: I wonder if there's anything trinity can add in the way of
> a test here?]
>
> Hi Peter,
>
> This looks like another bug in sched_setattr(). Using the program
> below (which you might find generally helpful for testing), I'm
> able to reliably freeze up my x64 (Intel Core i7-3520M Processor)
> system for up to about a minute when I run with the following
> command line:
>
> $ time sudo ./t_sched_setattr d 18446744072 18446744072 18446744073
>
> 'd' here means use SCHED_DEADLINE, then the remaining arguments
> are the Runtime, Deadline, and Period, expressed in *seconds*.
> (Those number by the way are just a little below 2^64.)
>
> Aside from interpreting its command-line arguments, all that the
> program does is call sched_setattr() and displays elapsed times.
> (By the way, on my system I see some weird effects for time(2),
> presumably VDSO effects.)
>
> Here's sample run:
>
> time sudo ./t_sched_setattr d 18446744072 18446744072 18446744073
> Runtime = 18446744072000000000
> Deadline = 18446744072000000000
> Period = 18446744073000000000
> About to call sched_setattr()
> Successful return from sched_setattr() [6 seconds]
>
> real 0m40.421s
> user 0m3.097s
> sys 0m30.804s
>
> After unfreezing the machine is fine, while the program is running,
> the machine is pretty unresponsive.
>
> I'm on kernel 3.15-rc4.
Hi Peter,
I realize my speculation was completely off the mark. time(2) really
is reporting the truth, and the sched_setattr() call returns immediately.
But it looks like with these settings the deadline scheduler gets itself
into a confused state. The process chews up a vast amount of CPU time
for the few actions (including process teardown) that occur after
the sched_setattr() call, and since the SCHED_DEADLINE process has
priority over everything else, the system locks up.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2014-05-12 6:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-11 14:54 [BUG] sched_setattr() SCHED_DEADLINE hangs system Michael Kerrisk (man-pages)
2014-05-11 17:47 ` Michael Kerrisk (man-pages)
2014-05-12 6:53 ` Michael Kerrisk (man-pages) [this message]
2014-05-12 8:47 ` Peter Zijlstra
2014-05-12 9:19 ` Michael Kerrisk (man-pages)
2014-05-12 12:30 ` Peter Zijlstra
2014-05-13 9:57 ` Juri Lelli
2014-05-13 10:43 ` Peter Zijlstra
2014-05-13 12:11 ` Juri Lelli
2014-05-13 12:46 ` Michael Kerrisk (man-pages)
2014-05-19 13:07 ` [tip:sched/core] sched/deadline: Restrict user params max value to 2^63 ns tip-bot for Juri Lelli
2014-05-22 12:25 ` tip-bot for Juri Lelli
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=53707007.3080003@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=davej@redhat.com \
--cc=juri.lelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=raistlin@linux.it \
/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.