All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: Cliff Brake <cliff.brake@gmail.com>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: Priority of serial driver
Date: Sat, 22 Sep 2007 16:15:23 -0300	[thread overview]
Message-ID: <20070922191522.GA4887@ghostprotocols.net> (raw)
In-Reply-To: <f96d234e0709221122g36dab213y41645c159d620c8e@mail.gmail.com>

Em Sat, Sep 22, 2007 at 02:22:00PM -0400, Cliff Brake escreveu:
> I have a system where I am doing the following on a PXA270 ARM system:
> 
> An applications is sending and receiving a packet on a serial port
> every 40ms.  With 2.6.20, I simply enabled kernel preemption and set
> the priority of my application to real-time, and it worked great, no
> matter what the system load.

You didn't made it clear what exactly is the kernel version you are
using. You mention 2.6.20, but is this with or without the PREEMPT_RT
patch?
 
> With 2.6.23-rc6, I have enabled CONFIG_HIGH_RES_TIMERS &
> CONFIG_PREEMPT.  Scheduling in the real-time application is rock solid
> and looking at timing with a scope, and instrumenting the loop in the
> application indicates the 40ms is very solid.  However, it seems the
> receive data is getting stuck in the serial driver for relatively long
> periods of time (>= 40ms), which is a problem in this system.
> 
> Is there anything that would have changed between 2.6.20 and
> 2.6.23-rc6 that would explain this?  What priority do pieces of the
> serial driver run at?  Is there any way to make the serial driver run
> at high priority so that data is processed in a timely manner?

Look at the IRQ-<N> kernel thread that services the serial port hardware
interrupt, use chrt to bump its priority and see if it helps.

To see which is the interrupt:

[root@tonchinha ~]# dmesg | grep ttyS0
Kernel command line: root=/dev/hda1 console=ttyS0,115200 console=tty0
ignore_loglevel
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

Now check what is the default rt priority for its hard interrupt kernel
thread handler, "IRQ-4":

[root@tonchinha ~]# ps -C IRQ-4 -To pid,rtprio,cmd
PID   RTPRIO CMD
1721  50     [IRQ-4]
[root@tonchinha ~]# 

Use the `chrt' utility to bump the priority to, say, 75:

[root@tonchinha ~]# chrt -p 75 1721

Check again:

[root@tonchinha ~]# ps -C IRQ-4 -To pid,rtprio,cmd
PID   RTPRIO CMD
1721  75     [IRQ-4]

- Arnaldo

  reply	other threads:[~2007-09-22 19:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-22 18:22 Priority of serial driver Cliff Brake
2007-09-22 19:15 ` Arnaldo Carvalho de Melo [this message]
2007-09-24 14:50   ` Cliff Brake
2007-09-24 15:45     ` Cliff Brake
2007-09-24 17:51       ` Cliff Brake
2007-09-25  9:24         ` Esben Nielsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070922191522.GA4887@ghostprotocols.net \
    --to=acme@ghostprotocols.net \
    --cc=cliff.brake@gmail.com \
    --cc=linux-rt-users@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.