Need help debugging sp16.exe

[Richi Dubey]

>
> Your scheduler is a unique piece of software. It may be making assumptions
> that are not checked in the generic scheduler code. And checks in other
> schedulers are of no use to you.
> There may not be any but this is something to consider. There are existing
> checks scattered throughout the source. Do any need to be in your scheduler?

I understand. Thanks.


> Simulators tend to run slowly. They also may spend a long time when
> testing RTEMS executing the idle thread waiting for time to pass. Fast idle
> just says if a clock tick occurs while the idle thread is running, call
> clock tick over and over until another thread is unblocked and preempts
> idle.

This is hard to understand.

Looking across all failing tests usually helps. For some reason, one tends
> to be easier to debug than the others.

Got it. I'll read all the failing tests once.

Also some of the tests have a lot of code up front that doesn't impact what
> you are testing. It may be possible to disable early parts of sp16 to
> reduce what you have to step through and compare schedulers.d

This is great advice, thanks. How do I disable the early unwanted parts? I
can't comment it, nor can I set an appropriate breakpoint. What should I do?

> That's a bad typo or auto-correct. Probably should have been tactic.
> tracing

I understand. Thanks.

On Tue, Oct 13, 2020 at 11:06 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Mon, Oct 12, 2020 at 11:19 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Mon, Oct 12, 2020 at 10:47 AM Richi Dubey <richidubey at gmail.com>
> wrote:
> >>>
> >>> There are existing checks scattered throughout the source. Do any need
> to be in your scheduler?
> >>
> >> I don't understand. If there are already checks scattered through, why
> do I need more checks in my scheduler? Are these checks independent from
> the checks I might need in the scheduler? Please explain.
> >
> >
> > Your scheduler is a unique piece of software. It may be making
> assumptions that are not checked in the generic scheduler code. And checks
> in other schedulers are of no use to you.
> >
> > There may not be any but this is something to consider.
> >
> >>
> >>
> >>> + Looks like the bsp has fast idle on but that should not impact
> anything.
> >>
> >> What's fast idle? I found this. :p How can time run as fast as possible?
> >
> >
> > Simulators tend to run slowly. They also may spend a long time when
> testing RTEMS executing the idle thread waiting for time to pass. Fast idle
> just says if a clock tick occurs while the idle thread is running, call
> clock tick over and over until another thread is unblocked and preempts
> idle.
> >>
> >>
> >>> + Run this with the another scheduler and see if you can identify when
> that scheduler makes the decision you are missing. There has to be one of
> the scheduler hooks that is making a different decision. Run the test side
> by side with two different schedulers. Alternate forward motion in the two
> and compare the behaviour.
> >>
> >> This is genius. Thanks a lot. I'm gonna work on this.
> >>
> >>> + Adding trading might help but is probably more trouble to set up
> than just comparing good and bad schedulers in parallel.
> >>
> >> What's trading?
> >
> >
> > That's a bad typo or auto-correct. Probably should have been tactic.
> tracing
>
> >>
> >>
> >>> + Look at what every failing test is doing. May be a common issue and
> one is easier to debug
> >>
> >> Thanks. I'll check this.
> >
> >
> > Looking across all failing tests usually helps. For some reason, one
> tends to be easier to debug than the others.
> >
> > Also some of the tests have a lot of code up front that doesn't impact
> what you are testing. It may be possible to disable early parts of sp16 to
> reduce what you have to step through and compare schedulers.
> >
> > --joel
> >>
> >>
> >>
> >> On Sun, Oct 11, 2020 at 5:08 AM Joel Sherrill <joel at rtems.org> wrote:
> >>>
> >>>
> >>>
> >>> On Sat, Oct 10, 2020, 10:47 AM Richi Dubey <richidubey at gmail.com>
> wrote:
> >>>>
> >>>> Hi Mr. Huber,
> >>>>
> >>>> Thanks for checking in.
> >>>>
> >>>>> I suggested to enable your new scheduler implementation as the
> default
> >>>>> to check if it is in line with the standard schedulers. I would first
> >>>>> get some high level data. Select a BSP with good test results on a
> >>>>> simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run
> the
> >>>>> tests and record the test data. Then enable the SMP EDF scheduler as
> the
> >>>>> default, run the tests, record the data. Then enable your scheduler
> as
> >>>>> the default, run the tests, record the data. Then get all tests which
> >>>>> fail only with your scheduler.
> >>>>
> >>>> Yes, this is something I've already done based on your previous
> suggestion. I set SCHEDULER_STRONG_APA(the current RTEMS master's version)
> as the default scheduler for both sp and SMP and ran the test (on both
> sparc/leon3 and arm/realview_pbx_a9_qemu). Then I set
> SCHEDULER_STRONG_APA(my version) as the default scheduler for both sp and
> SMP and ran the test and compared it with the master's strong apa result.
> The following (extra) tests failed:
> >>>>
> >>>>  sp02.exe
> >>>>  sp16.exe
> >>>>  sp30.exe
> >>>>  sp31.exe
> >>>>  sp37.exe
> >>>>  sp42.exe
> >>>>  spfatal29.exe
> >>>>  tm24.exe
> >>>>
> >>>>> Do a high level analysis of all failing
> >>>>>
> >>>>> tests. Try to figure out a new scenario for the test smpstrongapa01.
> >>>>
> >>>> Okay, I would look into this. This is a great suggestion, thanks!
> >>>>
> >>>>
> >>>>> Do all the development with RTEMS_DEBUG enabled!
> >>>>> Add _Assert() stuff to your scheduler. Check pre- and
> post-conditions of
> >>>>> all operations. Check invariants.
> >>>>
> >>>> How do I check postconditions? Using _Assert() or by manually
> debugging each function call?
> >>>
> >>>
> >>> There are existing checks scattered throughout the source. Do any need
> to be in your scheduler?
> >>>
> >>> Random thoughts:
> >>>
> >>> + Looks like the bsp has fast idle on but that should not impact
> anything.
> >>>
> >>> + Run this with the another scheduler and see if you can identify when
> that scheduler makes the decision you are missing. There has to be one of
> the scheduler hooks that is making a different decision. Run the test side
> by side with two different schedulers. Alternate forward motion in the two
> and compare the behaviour.
> >>>
> >>> + Adding trading might help but is probably more trouble to set up
> than just comparing good and bad schedulers in parallel.
> >>>
> >>> + Look at what every failing test is doing. May be a common issue and
> one is easier to debug
> >>>
> >>> --joel
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Oct 10, 2020 at 6:09 PM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
> >>>>>
> >>>>> Hello Richi,
> >>>>>
> >>>>> I suggested to enable your new scheduler implementation as the
> default
> >>>>> to check if it is in line with the standard schedulers. I would first
> >>>>> get some high level data. Select a BSP with good test results on a
> >>>>> simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run
> the
> >>>>> tests and record the test data. Then enable the SMP EDF scheduler as
> the
> >>>>> default, run the tests, record the data. Then enable your scheduler
> as
> >>>>> the default, run the tests, record the data. Then get all tests which
> >>>>> fail only with your scheduler. Do a high level analysis of all
> failing
> >>>>> tests. Try to figure out a new scenario for the test smpstrongapa01.
> >>>>>
> >>>>> Do all the development with RTEMS_DEBUG enabled!
> >>>>>
> >>>>> Add _Assert() stuff to your scheduler. Check pre- and
> post-conditions of
> >>>>> all  operations. Check invariants.
> >>>>>
> >>>> _______________________________________________
> >>>> devel mailing list
> >>>> devel at rtems.org
> >>>> http://lists.rtems.org/mailman/listinfo/devel
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201016/6ba7ef9a/attachment-0001.html>