Fwd: Help with debugging a POSIX timing test.
Chirayu Desai
chirayudesai1 at gmail.com
Wed Nov 27 09:30:57 UTC 2013
On 27 November 2013 02:45, Joel Sherrill <joel.sherrill at 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.sherrill at oarcorp.com
> > <mailto:joel.sherrill at 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* <chirayudesai1 at gmail.com
> > <mailto:chirayudesai1 at gmail.com>
> > > <mailto:chirayudesai1 at gmail.com <mailto:chirayudesai1 at gmail.com>>>
> > > Date: 25 November 2013 15:30
> > > Subject: Re: Help with debugging a POSIX timing test.
> > > To: Joel Sherrill <joel.sherrill at oarcorp.com
> > <mailto:joel.sherrill at oarcorp.com>
> > > <mailto:joel.sherrill at oarcorp.com <mailto:
> joel.sherrill at oarcorp.com>>>
> > >
> > >
> > >
> > >
> > >
> > > On 25 November 2013 00:35, Joel Sherrill
> > <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>
> > > <mailto:joel.sherrill at oarcorp.com
> > <mailto:joel.sherrill at 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.sherrill at 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.sherrill at 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.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20131127/e8396cfb/attachment.html>
More information about the devel
mailing list