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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
