Help on tuning the Linux kernel for soft real-time requirements

[VanBaren, Gerald (AGRE)]

> -----Original Message-----
> From: linuxppc-embedded-bounces at ozlabs.org
> [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of
> Zajac Adam-AAZ004
> Sent: Friday, October 22, 2004 3:00 PM
> To: 'wd at denx.de'
> Cc: linuxppc-embedded at ozlabs.org
> Subject: RE: Help on tuning the Linux kernel for soft
> real-time requirements
>
> Wolfgang,
>
> >I'm not exaclty sure I really understand what  you  are  asking  for.
> >Isn't  sometimes  missing  the  deadlines what the "soft" is
> standing
> >for? ;-)
>
> I'm certainly not the one who would attempt to define the
> distinction between hard and soft real-time requirements
> (beyond the obvious notion of an absolute deterministic and
> an average response time). Just used that term casually as we
> wanted to meet application deadlines that were in order of
> seconds with some small room for a response variation (+/-
> milliseconds).
> What I referred to as "missed deadlines" were slips in order
> of +/- 20 seconds. This was way out of line.
>
> Do you know if sysstat RPM is available for PPC?
> It'd be nice to have tools like sar and iostat for debugging
> my problem.
>
> Regards,
> Adam

Hi Adam,

What you are quoting isn't a missed deadline in a soft real time system,
you are describing a full blown bug.  You are confusing your advisors by
mischaracterizing it.  Slips of a small number of milliseconds are
"missed deadlines."  Slips of 20 seconds are evidence of a full blown
bug such as interrupts being masked in the code and not unmasked (e.g.
an error path is taken that forgets to unmask the interrupts) or
priority inversion.

Priority inversion happens when a low priority task grabs a semaphore
which is then preempted by a higher priority task.  Meanwhile other high
priority tasks try to get the locking semaphore held by the low priority
task, but cannot get it because the low priority task has it locked and
other higher priority tasks prevent the low priority task from running
and releasing the semaphore.

I would be suspicious in your case of either priority inversion due to
different tasks printing to the serial port or of a miss-handling of
interrupt masking in the serial routine.

I would suggest you use the LTT.  My cohort in crime here says it works
well for this type of bug, although it can generate GOBS of data (as
Wolfgang pointed out).  Note that you can make custom log points and
insert them in both your driver and also your application code so you
can see what your application code is doing too when everything
paaaaaaaaaaaaaaaaaaaaaaaaaaaaaauses.

gvb


******************************************
The following messages are brought to you by the Lawyers' League of
IdioSpeak:

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************