I am trying to run a command in realtime mode just to see if it behaves any different as far as timings are concerned.
Man page says:
CHRT(1) Linux User’s Manual CHRT(1)
NAME chrt - manipulate real-time attributes of a process
SYNOPSIS chrt [options] prio command [arg]... chrt [options] -p [prio] pid
So, I tried the first example instance above:
$ sudo chrt 0 ./freq -s120 -u0 -r chrt: failed to set pid 0's policy: Invalid argument
Hmmm. I thought the arg after chrt should be the value of the priority, since options to chrt are optional!!!
Another broken utility???
Soo I tried:
$ sudo chrt ./freq -s120 -u0 -r # i.e. no value for priority chrt: failed to set pid 0's policy: Invalid argument
Anyone tried this before? Any clues?
On Sun, Sep 26, 2010 at 12:33 PM, JD jd1008@gmail.com wrote:
I am trying to run a command in realtime mode just to see if it behaves any different as far as timings are concerned.
Man page says:
chrt - manipulate real-time attributes of a process
chrt [options] prio command [arg]... chrt [options] -p [prio] pid
So, I tried the first example instance above:
$ sudo chrt 0 ./freq -s120 -u0 -r chrt: failed to set pid 0's policy: Invalid argument
Soo I tried:
$ sudo chrt ./freq -s120 -u0 -r # i.e. no value for priority chrt: failed to set pid 0's policy: Invalid argument
You probably have to enclose "./freq..." in single or double quotes.
On 09/26/2010 10:04 AM, Tom H wrote:
On Sun, Sep 26, 2010 at 12:33 PM, JDjd1008@gmail.com wrote:
I am trying to run a command in realtime mode just to see if it behaves any different as far as timings are concerned.
Man page says:
chrt - manipulate real-time attributes of a process
chrt [options] prio command [arg]... chrt [options] -p [prio] pid
So, I tried the first example instance above:
$ sudo chrt 0 ./freq -s120 -u0 -r chrt: failed to set pid 0's policy: Invalid argument
Soo I tried:
$ sudo chrt ./freq -s120 -u0 -r # i.e. no value for priority chrt: failed to set pid 0's policy: Invalid argument
You probably have to enclose "./freq..." in single or double quotes.
$ sudo chrt 0 "./freq -s120 -u0 -r" chrt: failed to set pid 0's policy: Invalid argument $ sudo chrt 0 './freq -s120 -u0 -r' chrt: failed to set pid 0's policy: Invalid argument
Obviously chrt is busted as far as having a command as one of it's args is concerned. Or so I thought....
Then I decided to use the second form of the command where a PID is sspecified, ala
chrt [options] -p [prio] PID
The man page says that the option -f sets the scheduling type to FIFO.
So I concocted a way to do that by this script:
#!/bin/sh sudo nice --60 ./freq -s120 -u0 -r & ps -ef | grep freq | egrep -v 'grep|sudo' | awk '{ print $2 }' | xargs sudo chrt -f -p 0
When I ran it, I got: [1] 11340 <<<<< This is the pid of the sudo, and not of ./freq pid 11348's current scheduling policy: SCHED_OTHER pid 11348's current scheduling priority: 0
So, the gist of this is that I requested a FIFO scheduling policy by the -f option to chrt. Yet, chrt decided to use SCHED_OTHER.
So, I downloaded the source rpm (util-linux-ng) and looked at the file chrt.c
The joke is, it does not even parse it's args for the command the user wants to run. So, the man page ought to dump the first form of invoking chrt; namely
chrt [options] prio command [arg]...
'cause it is not even being looked for in the args.
To wit (from soource code):
while((i = getopt_long(argc, argv, "+bfiphmorvV", longopts, NULL)) != -1) { int ret = EXIT_FAILURE;
switch (i) { case 'b': #ifdef SCHED_BATCH policy = SCHED_BATCH; #endif break; case 'f': policy = SCHED_FIFO; break; case 'i': #ifdef SCHED_IDLE policy = SCHED_IDLE; #endif break; case 'm': show_min_max(); return 0; case 'o': policy = SCHED_OTHER; break; case 'p': errno = 0; pid = strtol(argv[argc - 1], NULL, 10); if (errno) err(EXIT_FAILURE, _("failed to parse pid")); break; case 'r': policy = SCHED_RR; break; case 'v': verbose = 1; break; case 'V': printf("chrt (%s)\n", PACKAGE_STRING); return 0; case 'h': ret = EXIT_SUCCESS; default: show_usage(ret); } }
if (((pid > -1) && argc - optind < 1) || ((pid == -1) && argc - optind < 2)) show_usage(EXIT_FAILURE); The if condition always succeeds whether or not you embed the command argument and it's args in single or double quotes. In fact it never scans of the user command!
On 09/26/2010 12:22 PM, JD wrote:
$ sudo chrt 0 "./freq -s120 -u0 -r" chrt: failed to set pid 0's policy: Invalid argument $ sudo chrt 0 './freq -s120 -u0 -r' chrt: failed to set pid 0's policy: Invalid argument
0 isn't valid for the default policy (SCHED_RR). "chrt -m" displays the minimum and maximum values valid for each of the policies.
#!/bin/sh sudo nice --60 ./freq -s120 -u0 -r& ps -ef | grep freq | egrep -v 'grep|sudo' | awk '{ print $2 }' | xargs sudo chrt -f -p 0
When I ran it, I got: [1] 11340<<<<< This is the pid of the sudo, and not of ./freq pid 11348's current scheduling policy: SCHED_OTHER pid 11348's current scheduling priority: 0
So, the gist of this is that I requested a FIFO scheduling policy by the -f option to chrt. Yet, chrt decided to use SCHED_OTHER.
I don't know about the output, but again, 0 isn't valid for the FIFO policy.
The joke is, it does not even parse it's args for the command the user wants to run.
Yes, it does:
# chrt 5 ls bin boot cgroup dev etc home lib lib64 lost+found media mnt opt proc root sbin selinux srv sys tmp usr var
To wit (from soource code):
while((i = getopt_long(argc, argv, "+bfiphmorvV", longopts,NULL)) != -1)
getopt_long won't return non-option arguments. Those are parsed later. getopt returns option arguments and modifies argv to remove them after parsing. Non-option arguments are left in argv.
On 09/26/2010 06:04 PM, Gordon Messmer wrote:
On 09/26/2010 12:22 PM, JD wrote:
$ sudo chrt 0 "./freq -s120 -u0 -r" chrt: failed to set pid 0's policy: Invalid argument $ sudo chrt 0 './freq -s120 -u0 -r' chrt: failed to set pid 0's policy: Invalid argument
0 isn't valid for the default policy (SCHED_RR). "chrt -m" displays the minimum and maximum values valid for each of the policies.
#!/bin/sh sudo nice --60 ./freq -s120 -u0 -r& ps -ef | grep freq | egrep -v 'grep|sudo' | awk '{ print $2 }' | xargs sudo chrt -f -p 0
When I ran it, I got: [1] 11340<<<<< This is the pid of the sudo, and not of ./freq pid 11348's current scheduling policy: SCHED_OTHER pid 11348's current scheduling priority: 0
So, the gist of this is that I requested a FIFO scheduling policy by the -f option to chrt. Yet, chrt decided to use SCHED_OTHER.
I don't know about the output, but again, 0 isn't valid for the FIFO policy.
So that was the problem! I was still thinking within the normal process priority values: lower numbers mean higher pri. That's what made me look at the source code and I thought well it does not parse command line, otherwise why would it quit parsiing. Should've RTwholeFM :) :)
The joke is, it does not even parse it's args for the command the user wants to run.
Yes, it does:
# chrt 5 ls bin boot cgroup dev etc home lib lib64 lost+found media mnt opt proc root sbin selinux srv sys tmp usr var
To wit (from soource code):
while((i = getopt_long(argc, argv, "+bfiphmorvV", longopts,NULL)) != -1)
getopt_long won't return non-option arguments. Those are parsed later. getopt returns option arguments and modifies argv to remove them after parsing. Non-option arguments are left in argv.
On Sun, Sep 26, 2010 at 3:22 PM, JD jd1008@gmail.com wrote:
On 09/26/2010 10:04 AM, Tom H wrote:
On Sun, Sep 26, 2010 at 12:33 PM, JDjd1008@gmail.com wrote:
I am trying to run a command in realtime mode just to see if it behaves any different as far as timings are concerned.
Man page says:
chrt - manipulate real-time attributes of a process
chrt [options] prio command [arg]... chrt [options] -p [prio] pid
So, I tried the first example instance above:
$ sudo chrt 0 ./freq -s120 -u0 -r chrt: failed to set pid 0's policy: Invalid argument
Soo I tried:
$ sudo chrt ./freq -s120 -u0 -r # i.e. no value for priority chrt: failed to set pid 0's policy: Invalid argument
You probably have to enclose "./freq..." in single or double quotes.
$ sudo chrt 0 "./freq -s120 -u0 -r" chrt: failed to set pid 0's policy: Invalid argument $ sudo chrt 0 './freq -s120 -u0 -r' chrt: failed to set pid 0's policy: Invalid argument
Obviously chrt is busted as far as having a command as one of it's args is concerned. Or so I thought....
Then I decided to use the second form of the command where a PID is sspecified, ala
chrt [options] -p [prio] PID
The man page says that the option -f sets the scheduling type to FIFO.
So I concocted a way to do that by this script:
#!/bin/sh sudo nice --60 ./freq -s120 -u0 -r & ps -ef | grep freq | egrep -v 'grep|sudo' | awk '{ print $2 }' | xargs sudo chrt -f -p 0
When I ran it, I got: [1] 11340 <<<<< This is the pid of the sudo, and not of ./freq pid 11348's current scheduling policy: SCHED_OTHER pid 11348's current scheduling priority: 0
So, the gist of this is that I requested a FIFO scheduling policy by the -f option to chrt. Yet, chrt decided to use SCHED_OTHER.
So, I downloaded the source rpm (util-linux-ng) and looked at the file chrt.c
The joke is, it does not even parse it's args for the command the user wants to run. So, the man page ought to dump the first form of invoking chrt; namely
chrt [options] prio command [arg]...
'cause it is not even being looked for in the args.
To wit (from soource code):
while((i = getopt_long(argc, argv, "+bfiphmorvV", longopts, NULL)) != -1) { int ret = EXIT_FAILURE;
switch (i) { case 'b': #ifdef SCHED_BATCH policy = SCHED_BATCH; #endif break; case 'f': policy = SCHED_FIFO; break; case 'i': #ifdef SCHED_IDLE policy = SCHED_IDLE; #endif break; case 'm': show_min_max(); return 0; case 'o': policy = SCHED_OTHER; break; case 'p': errno = 0; pid = strtol(argv[argc - 1], NULL, 10); if (errno) err(EXIT_FAILURE, _("failed to parse pid")); break; case 'r': policy = SCHED_RR; break; case 'v': verbose = 1; break; case 'V': printf("chrt (%s)\n", PACKAGE_STRING); return 0; case 'h': ret = EXIT_SUCCESS; default: show_usage(ret); } }
if (((pid > -1) && argc - optind < 1) || ((pid == -1) && argc - optind < 2)) show_usage(EXIT_FAILURE);
The if condition always succeeds whether or not you embed the command argument and it's args in single or double quotes. In fact it never scans of the user command!
You should be able to use pgrep in your script - and you probably should launch it with "sudo ..." or "su -c ..." rather than include two sudos in it.
I'd never used (or heard of) chrt before.
I've just tried "chrt 21 yum update" and it ran.
Also "chrt --help" offers different/better help than "man chrt".
-
Gordon Messmer -
JD -
Tom H