On Sun, 5 Oct 2014, Armin Steinhoff wrote:
> But this doesn't explain why pthread_schedparam had problems with an
> earlier PREEMPT_RT kernel!
> And pointing out such a problem and problems of "ps" is for you:
Lets look at the problems.
I built the random kernel version which you used for testing and
against which you reported a bug.
# uname -a
# Linux fuzz 3.4.0-rc7-rt7+ #42 SMP PREEMPT RT Sun Oct 5 15:52:24 CEST 2014 x86_64 GNU/Linux
Using the following test program:
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <pthread.h>
static void *fn(void *p)
{
while (1) sleep(1);
return NULL;
}
int main(void)
{
struct sched_param sp;
pthread_t t;
if (pthread_create(&t, NULL, fn, NULL) != 0)
exit(1);
memset(&sp, 0, sizeof(sp));
sp.__sched_priority = 80;
if (pthread_setschedparam(t, SCHED_FIFO, &sp) != 0)
exit(1);
printf("OK\n");
sleep(60);
exit(0);
}
Which is exactly what you claim to be broken.
# ./sp
OK
# strace ./sp 2>&1 | grep sched
sched_setscheduler(2197, SCHED_FIFO, { 80 }) = 0
#
Strange. It works.
Now lets verify the latest 3.4 version.
# uname -a
# Linux fuzz 3.4.97-rt121+ #43 SMP PREEMPT RT Sun Oct 5 15:57:30 CEST 2014 x86_64 GNU/Linux
Your claim now is that the priorities of random other programs are
modified after the first thread is started and its priority is set. So
the issue should be observable with the above test program as well.
# ps -elLf >a.txt
# cat a.txt | awk '{ print $7; }' | grep 99
# cat a.txt | awk '{ print $8; }' | grep 19
# ./sp &
OK
# ps -elLf >b.txt
# cat b.txt | awk '{ print $7; }' | grep 99
# cat b.txt | awk '{ print $8; }' | grep 19
# diff -u a.txt b.txt
--- a.txt 2014-10-05 16:02:08.994360001 +0200
+++ b.txt 2014-10-05 16:02:17.518360000 +0200
@@ -102,4 +102,6 @@
0 S tglx 1892 1891 1892 0 1 80 0 - 5250 wait 15:59 pts/0 00:00:00 -bash
4 S root 1973 1892 1973 0 1 80 0 - 10497 wait 15:59 pts/0 00:00:00 su
4 S root 1974 1973 1974 0 1 80 0 - 4928 wait 15:59 pts/0 00:00:00 bash
-4 R root 2005 1974 2005 0 1 80 0 - 4770 - 16:02 pts/0 00:00:00 ps -elLf
+4 S root 2006 1974 2006 0 2 80 0 - 3638 hrtime 16:02 pts/0 00:00:00 ./sp
+1 S root 2006 1974 2007 0 2 -21 - - 3638 hrtime 16:02 pts/0 00:00:00 ./sp
+4 R root 2008 1974 2008 0 1 80 0 - 4770 - 16:02 pts/0 00:00:00 ps -elLf
Even more strange. Works as well. And the output of 'ps -elLf' for
'sp' is exactly matching the above program.
Now I really had to switch my brain off for this excercise because
with brain on, I already knew that neither sys_setschedparam() is or
was broken, nor the kernel randomly modifies priorities nor ps gives
randomized output.
I asked you at the beginning of this very thread to read
linux/Documentation/REPORTING-BUGS. You ignored that and came back
with more theories about kernel bugs and ps being broken.
Then despite the fact, that you failed to provide a proper bug report,
Carsten gave you enough hints to decode the issue.
But you insist on reporting bugs and problems and come up with more
theories about broken kernels and tools.
So you really expect the people who are willing to help you for free
and who gave you perfectly fine hints how to decode your problem,
should accept that you ignore their hints and advice?
That's blatant abuse. Abuse of those who try to guide you and those
who provided you with the technology on which you build products in
the first place. This is not how community support works.
Do you really expect, that we waste our time with someone who seeks
help and responds to hints and advise with:
> I have two version of the "man ps" ... the statement of man page 1p
> isn't applicable for SCHED_FIFO/SCHED_RR because 99 is right here the
> highest prio for the scheduling.
So after carefully studying man ps, you came to that conclusion and
certainly have fully understood how all that works.
> Sorry for not bothering about the confusing handling of priorities
> within LINUX ..."
Or perhaps not?
So you make claims about priorities and cannot be bothered to figure
out how the priority handling of Linux works?
Why should we be bothered to solve your business problems, if you are
outright refusing to do your homework before stealing everyones time?
While I surely could have responded more politely, you might
understand that there are limits of patience and limits on tolerating
abusive behaviour.
Now back to your original question.
> And pointing out such a problem and problems of "ps" is for you:
A very good reason to ignore any further posts from you.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
