2004-04-14 14:23:47

by Calin A. Culianu

[permalink] [raw]
Subject: Shielded CPUs


This might be a bit off-topic (and might belong in the rtlinux mailing
list), but I wanted people's opinion on LKML...

There's an article in the May 2004 Linux Journal about some CPU affinity
features in Redhawk Linux that allow a process and a set of interrupts to
be locked to a particular CPU for the purposes of improving real-time
performance. This technique is dubbed CPU Shielding
(http://www.ccur.com/isddocs/wp-shielded-cpu.pdf) and the claim is made
that a user program that is thus configured (with the appropriately
patched kernel, of course) can acheive deterministic (hard) real-time
performance. The author claimed you can get (bounded) interrupt response
time in the 100s of microseconds, and he alluded to the fact that
scheduling jitter also is reduced and bounded with a hard limit.

Does this make any sense to anyone here?

Specifically, what about, among other things, priority inversion?

Presumably your high priority task is always undergoing some small amount
of priority inversion if it touches a spinlock. Worse yet, if your
process ever has to touch anything in the Linux kernel that needs to sleep
(such as, say, memory being swapped from disk) then your hard realtime
program has just failed to be hard realtime.

Does anyone know anything more about this? Is this magic?! The author of
this paper certainly makes it seem like it is...

Perplexedly yours,

-Calin




2004-04-14 14:38:11

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Shielded CPUs

On Wed, 2004-04-14 at 16:23, Calin A. Culianu wrote:
> This might be a bit off-topic (and might belong in the rtlinux mailing
> list), but I wanted people's opinion on LKML...
>
> There's an article in the May 2004 Linux Journal about some CPU affinity
> features in Redhawk Linux that allow a process and a set of interrupts to
> be locked to a particular CPU for the purposes of improving real-time
> performance.

well you can do both of those already in 2.6 and in all recent vendor
2.4's that I know of..... no patches needed.


Attachments:
signature.asc (189.00 B)
This is a digitally signed message part

2004-04-14 15:11:59

by Calin A. Culianu

[permalink] [raw]
Subject: Re: Shielded CPUs

On Wed, 14 Apr 2004, Arjan van de Ven wrote:

> On Wed, 2004-04-14 at 16:23, Calin A. Culianu wrote:
> > This might be a bit off-topic (and might belong in the rtlinux mailing
> > list), but I wanted people's opinion on LKML...
> >
> > There's an article in the May 2004 Linux Journal about some CPU affinity
> > features in Redhawk Linux that allow a process and a set of interrupts to
> > be locked to a particular CPU for the purposes of improving real-time
> > performance.
>
> well you can do both of those already in 2.6 and in all recent vendor
> 2.4's that I know of..... no patches needed.


Cool.. it's still not, strictly speaking, _hard_ realtime, though, is it?
Simply really good soft-realtime, right?


2004-04-14 15:17:09

by Arjan van de Ven

[permalink] [raw]
Subject: Re: Shielded CPUs


On Wed, Apr 14, 2004 at 11:11:47AM -0400, Calin A. Culianu wrote:
> On Wed, 14 Apr 2004, Arjan van de Ven wrote:
>
> > On Wed, 2004-04-14 at 16:23, Calin A. Culianu wrote:
> > > This might be a bit off-topic (and might belong in the rtlinux mailing
> > > list), but I wanted people's opinion on LKML...
> > >
> > > There's an article in the May 2004 Linux Journal about some CPU affinity
> > > features in Redhawk Linux that allow a process and a set of interrupts to
> > > be locked to a particular CPU for the purposes of improving real-time
> > > performance.
> >
> > well you can do both of those already in 2.6 and in all recent vendor
> > 2.4's that I know of..... no patches needed.
>
>
> Cool.. it's still not, strictly speaking, _hard_ realtime, though, is it?
> Simply really good soft-realtime, right?

yep. Hard real time means you need to get a hard RT OS code. Simple as that.
And you'll always see that those cores are kept relatively small so that the
vendor can basically prove it's RT correctness.


Attachments:
(No filename) (1.00 kB)
(No filename) (189.00 B)
Download all attachments