Fwd: Help with debugging a POSIX timing test.
Joel Sherrill
joel.sherrill at OARcorp.com
Wed Nov 27 17:11:23 UTC 2013
On 11/27/2013 3:30 AM, Chirayu Desai wrote:
>
>
>
> On 27 November 2013 02:45, Joel Sherrill <joel.sherrill at oarcorp.com
> <mailto: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.
On tests where context switches are forced and intended,
I like to add explicit comments indicating the points
they are intended.
And when debugging, you should be able to add prints
at those points and see the program switch from
task to task as you intended.
> 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.
We think it was an import problem for Melange or our
script based on the "," in the description. Watch
the .csv file on future ones to be sure.
> Feel free to ask questions about what the code
> is doing.
>
> The printfs made it really clear this time, thanks.
:)
--joel
> 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>
> > <mailto: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>>
> > > <mailto: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>>
> > > <mailto: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>>
> > > <mailto: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
>
>
--
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
More information about the devel
mailing list