Allow users to set the "none" class on processes. Using the
none class has the distict advantage that the io priority
is inherited from the cpu nice level. Update the man page
to reflect the change.
Signed-off-by: Jakob Unterwurzacher <jakobunt@gmail.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
SCHED_FIFO, SCHED_OTHER, SCHED_RR are part of POSIX 1003.1b Process
Scheduling, so it is correct to assume they always exists.
SCHED_BATCH and SCHED_IDLE are Linux specific, we should not assume
they exists.
Defining SCHED_BATCH and SCHED_IDLE to random values (ie the ones found
on Linux systems) is not an option as they may *collide* with the one of
other systems. For example on GNU/kFreeBSD we have:
#define SCHED_RR 3
and on Linux we have:
#define SCHED_BATCH 3
[kzak@redhat.com: - add "Linux specific" notes to chrt.1
- add a note about BATCH and PR conflict to
this commit message]
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Karel Zak <kzak@redhat.com>
Mention that only SCHED_FIFO, SCHED_OTHER and SCHED_RR are part of
POSIX 1003.1b Process Scheduling in chrt.1.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
% chrt -i 0 ./a.out &
[1] 60479
% chrt -p 60479
pid 60479's current scheduling policy: SCHED_IDLE
SCHED_RR
pid 60479's current scheduling priority: 0
We have a spurious and incorrect SCHED_RR in there...
Address-Red-Hat-Bugzilla: #483706
Signed-off-by: Karel Zak <kzak@redhat.com>
We practically have three io scheduling classes. The "none" is
de facto "best-effort" class for processes that has not asked
for io priority.
Signed-off-by: Karel Zak <kzak@redhat.com>
Extend the ionice man page to explain the "none" class and how the
cpu-nice => io-priority inheritance works.
Signed-off-by: Jakob Unterwurzacher <jakobunt@gmail.com>
* cleanup usage() output
* check strtol(); don't ignore wrong command line options
The original ionice design was a little broken, because it was
possible to specify a PID and also a COMMAND:
ionice -c2 -p 123 /bin/foo
but the command /bin/foo was executed without requested scheduling
class. That's stupid behaviour.
Now you have to use "-p PID" **or** COMMAND, but not both. Nothing is
ignored and all options are checked.
Signed-off-by: Karel Zak <kzak@redhat.com>
Makes ionice -p usable like renice, this time backwards compatible
[kzak@redhat.com: - fix coding style
- add ioprio_setpid()]
Signed-off-by: Stephan Maka <stephan@spaceboyz.net>
Signed-off-by: Karel Zak <kzak@redhat.com>
This patch allows "tolerant" behavior, i.e. proceeding even if
priority could not be set. This might be of use in case something
(selinux, old kernel, etc.) does not allow the requested scheduling
priority to be set.
This could be to some extend done as follows:
ionice -c3 command || command
but the downside is that one could not really tell if what failed was
setting priority or command itself, which could result in duplicate
command run.
This patch solves the situation, so that user can do
ionice -t -c3 command
Addresses-Red-Hat-Bugzilla: #443842
Signed-off-by: Lubomir Kundrak <lkundrak@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
The idle class is safe for non-root users since 2.6.25.
http://lwn.net/Articles/266256/
Addresses-Red-Hat-Bugzilla: #443823
Signed-off-by: Karel Zak <kzak@redhat.com>
Print error in case execvp fails and use exit macros.
Based on patch by Bernhard Voelker <mail@bernhard-voelker.de>
Signed-off-by: Matthias Koenig <mkoenig@suse.de>
Signed-off-by: Karel Zak <kzak@redhat.com>
Some architectures do no reliably provide sched_getaffinity, so make sure the
define exists before we try using it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The idle class has no class data. It will print a warning if
a prio argument is given for it, since this will be ignored.
Output for idle class will not contain prio data.
Signed-off-by: Matthias Koenig <mkoenig@suse.de>
It's better to use glibc SYS_ioprio_{set,get} definitions rather than an
incomplete (not all archs) and hardcoded version from ionice.c.
Signed-off-by: Karel Zak <kzak@redhat.com>
This patch makes the taskset command independent of the system's maximum
number of cpus (CONFIG_NR_CPUS). The maximum for CONFIG_NR_CPUS is a
moving target.
With this patch the size of the systems's cpumask_t is gotten from
sched_getaffinity(2).
This patch uses variable length bitmasks borrowed from Paul Jackson's
variable size bitmask routines (hence I kept his copyright notice).
This replaces the use of the glibc CPU_SETSIZE, CPU_SET, CPU_ZERO and
CPU_ISSET macros which depend on a hardcoded size for cpu_set_t.
(also fixes one little nit: the -V option is "-v" in the built-in help, so
changed the built-in help)
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
This is temporary workaround and it will be removed in 2.14 when
minimal number of people will use old systems where is not defined
SCHED_BATCH in (bits/)sched.h.
Signed-off-by: Karel Zak <kzak@redhat.com>
The generated autotools stuff shouldn't be maintained by SCM. After check out
from git use ./autogen.sh. For more details see README.devel.
Signed-off-by: Karel Zak <kzak@redhat.com>
Karel Zak
Peter Breitenlohner
Jakob Unterwurzacher
Aurelien Jarno
Martin Steigerwald
Stephan Maka
Lubomir Kundrak
James Youngman
Stepan Kasal
Mike Frysinger
Matthias Koenig
LaMont Jones
David Miller
Cliff Wickman