On 27 November 2013 02:45, Joel Sherrill <joel.sherr...@oarcorp.com> wrote:
> Hi > > This should be closer than the version you posted > on Melange. I added printf's to help show where > the context switches from one thread to another > were occurring. See if you can follow what is > going on. > Yes, I'm able to understand the context switches now. > > Remember the test description is: > > pthread_setschedparam - lower own priority, preempt which means that the benchmark operation starts > in one thread which lowers its priority allowing > another thread to run. When that thread runs it > will stop the timer and report. > I missed that, my bad. > > Feel free to ask questions about what the code > is doing. > The printfs made it really clear this time, thanks. > > On 11/25/2013 9:49 PM, Chirayu Desai wrote: > > > > > > > > On 26 November 2013 00:40, Joel Sherrill <joel.sherr...@oarcorp.com > > <mailto:joel.sherr...@oarcorp.com>> wrote: > > > > On 11/25/2013 10:58 AM, Chirayu Desai wrote: > > > > > > Sorry, I sent the last message to only Joel. > > > > I MIGHT have eventually gotten to it. But am swamped. > > > > > ---------- Forwarded message ---------- > > > From: *Chirayu Desai* <chirayudes...@gmail.com > > <mailto:chirayudes...@gmail.com> > > > <mailto:chirayudes...@gmail.com <mailto:chirayudes...@gmail.com>>> > > > Date: 25 November 2013 15:30 > > > Subject: Re: Help with debugging a POSIX timing test. > > > To: Joel Sherrill <joel.sherr...@oarcorp.com > > <mailto:joel.sherr...@oarcorp.com> > > > <mailto:joel.sherr...@oarcorp.com <mailto: > joel.sherr...@oarcorp.com>>> > > > > > > > > > > > > > > > > > > On 25 November 2013 00:35, Joel Sherrill > > <joel.sherr...@oarcorp.com <mailto:joel.sherr...@oarcorp.com> > > > <mailto:joel.sherr...@oarcorp.com > > <mailto:joel.sherr...@oarcorp.com>>> wrote: > > > > > > Now that I can see and run the code, a few things > > > jump out. > > > > > > + POSIX priorities -- lower numerically ==> more important > > > + You did &Thread_Id to calls after created. The & isn't > > > supposed to be there. > > > > > > + &policy should be the second argument to > > > pthread_getschedparam. > > > > > > This explains the ESRCH I was getting. > > > > Yep. And one of the compiler warnings as well. :) > > > > > + Pay attention to compiler warnings. :) > > > > > > Sorry for not doing so. > > > > No problem. This is a good example of how properly addressing > > the warning would have fixed the issue with no time in the > > debugger. Good programming practices try to keep you out of > > a debugger. :) > > > > > + Benchmark time is initialized IMMEDIATELY BEFORE the > > > single operation under test. We try to avoid including > > > anything. > > > > > > Got it. > > > > > > > > > I have attached a new version of init.c with comments > > > hacked in and changes. > > > > > > Thanks. > > > > > > > > > The big thing I tried to put in a comment block is that > > > the way this test is structured, it includes the hidden > > > start up time for the first time test_thread(0 runs. > > > I tried to write up notes on how to modify the test > > > to avoid that. > > > > > > I was unable to understand all of it. > > > From what I understood, POSIX_Init is called first, which > > > cals benchmark_pthread_setschedparam. > > > That creates a new thread, gets the priority and policy, and then > > > setschedparam is called > > > with the new (lowered) priority, which is what we want to test. > > > > pthread_create() creates and starts the thread. If it is > > more important than POSIX_Init(), it will immediately be > > switched to and run. But it isn't so it won't run until > > POSIX_Init() lowers its priority. > > > > > > That makes it much more clear. > > > > > > > > > For convenience, I would add a helper routine like > > > this: > > > > > > void set_thread_priority( id, new_priority ) > > > > > > and call it. It will greatly simplify the code. > > > > > > Noted, I will do that after I get a better understanding of the > code. > > > > Since you will be changing priority multiple times to switch > > back and forth, this will really help tighten the code. > > > > Done [0] :) > > > > > > > > > I hope I didn't fall into the inverse > > > priority range trap in those instructions.... > > > > > > WARNING: POSIX priorities run INVERSE from the internal > > > priorities but in gdb if you print: > > > > > > p _Per_CPU_Information.per_cpu.executing->current_priority > > > > > > You will see the internal priority (NOT POSIX priority) > > > of the currently running thread. 1 is most important > > > and 255 is the IDLE task. > > > > > > I'm confused. > > > Per > > > http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__POSIX__PRIORITY.html#gada0c9a015d42fd545af7454f1ca0d098 > , > > > "RTEMS Core has priorities run in the opposite sense of the POSIX > > API." > > > So, for this task, lowering the POSIX priority is what we want, it > is > > > the output I'm getting which confuses me > > > > > > Original priority: 2 > > > Lowered priority: 4 > > > > I am going to do this as a mix of internal and > > POSIX priorities > > > > Internal 255 is the lowest priority and illegal in POSIX. > > Internal 253 = POSIX_Init() at start (POSIX 2) > > see cpukit/posix/src/pthread.c for the default attributes > > > > Where you say lowered, it is actually becoming more important > > and moving to a numeric value with numbers above and below. > > At 2, there is little room below it. It is the next to lowest > > POSIX priority value. > > > > test_thread() is created at priority 2 also because the > > attributes are NULL. > > > > What you print as "Lowered priority" is actually the priority > > of test_thread() if I am reading things correctly. > > > > Hint: Make your set priority helper take (const char *, id, priority) > > and you can print the thread name in debug messages. :) > > > > When I break at test_thread(), the priority is POSIX=4, Internal=251 > > > > I'm getting the hang of this now. > > > > > > > So the numbers you pick are important to switch back and > > > forth between the tasks. > > > > > > I think the test is pretty close in spite of all that I > > > wrong. I stepped through the code attached and it is > > > doing the right thing EXCEPT including the thread hidden > > > start time. :) > > > > > > Benchmark programs are hard to get right but fun to write. > > > > > > Indeed > > > > :) > > > > Hope this helps. > > > > Stepping in gdb and printing the priority of the current thread > > helps. It will be the internal priority though. > > > > b POSIX_Init > > b test_thread > > > > and use > > > > p _Per_CPU_Information.per_cpu.executing->current_priority > > > > Using breakpoints did help, thanks. > > > > I have attached a new patch, and cross-posted it to melange as well. > > > > > > > > > > --joel > > > > > > On 11/24/2013 11:50 AM, Joel Sherrill wrote: > > > > Sorry to be lazy/stupid but how to I download just > > > > the diff to see what's going on? I am not that > > > > github literate. > > > > > > > > --joel > > > > > > > > On 11/24/2013 11:28 AM, Chirayu Desai wrote: > > > >> Hello everyone. > > > >> > > > >> I am Chirayu Desai, a high school student, currently > > participating in > > > >> Google Code-In 2013 > > > >> > > > >> I have currently working on the task [0], but I'm having > > some trouble > > > >> trying to get my code[1] to work. > > > >> > > > >> The task is to create a POSIX timing test psxtmthread05. > > > >> The test case is: pthread_setschedparam() - lower own > priority. > > > >> I managed to write up something [2], but it doesn't work. > > > >> The GDB output is: > > > >> > > > >> (gdb) r > > > >> Starting program: > > > >> > > > > > > /home/cdesai/rtems/b-sis/sparc-rtems4.11/c/sis/testsuites/psxtmtests/psxtmthread05/psxtmthread05.exe > > > >> > > > >> > > > >> *** POSIX TIME TEST PSXTMTHREAD05 *** > > > >> getschedparam: 3 > > > >> Original priority: 5 > > > >> Lowered priority: 4 > > > >> setschedparam: 3 > > > >> pthread_setschedparam - lower own priority 2226 > > > >> *** END OF POSIX TIME TEST PSXTMTHREAD05 *** > > > >> [Inferior 1 (process 42000) exited normally] > > > >> > > > >> [0]: > > > >> > > > > > > http://www.google-melange.com/gci/task/view/google/gci2013/6383096106582016 > > > >> [1]: > https://github.com/chirayudesai/rtems/tree/psxtmthread05 > > > >> [2]: > > > > > > https://github.com/chirayudesai/rtems/commit/890cebf084ca2a3815e3049a766276ddcdb0188a > > > >> > > > >> P.S. This is my first post to this list, so excuse me for > any > > > mistakes. > > > >> > > > >> Regards, > > > >> Chirayu Desai > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Joel Sherrill, Ph.D. Director of Research & > > Development > > > joel.sherr...@oarcorp.com On-Line Applications Research > > > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > > > Support Available (256) 722-9985 > > > > > > > > > > > > > > > > > -- > > Joel Sherrill, Ph.D. Director of Research & Development > > joel.sherr...@oarcorp.com On-Line Applications Research > > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > > Support Available (256) 722-9985 > > > > > > > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 >
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
