[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preemptive patch for etrax kernel?
On torsdagen den 4 april 2002 18.28, Pieter Grimmerink wrote:
> > > My main concern is for an application where we are a slave on a serial
> > > bus via a normal comport, and therefore have to respond to commands
> > > within a few milliseconds.
> > Why?
> > What will the problem be if it takes 10 ms? 100 ms?
> > 10 ms should be achievable with Mortons patch on 100 MHz CPU.
> This bus master requires me to answer within a few milliseconds, after this
> it will poll the next device.
A few milliseconds is tough on low frequency hardware.
But it also depends on what the other processes do.
If they mostly are idle, or running computations (user space).
In that case even an unpatched kernel is OK - but you have to set the
priority class and lock memory.
With the patch you can do more. Work with files (possibly not on JFFS),
have applications that swap, use XWindow (yea, right :-)
The target application has really been a multimedia workstation.
> > > I don't think you can call this requirement a hard realtime one, and I
> > > don't look forward to porting any of the realtime patches...
> > Have you looked at any?
> I've tried RTAI on i386, but it seems to have a lot of architecture
RTAI is a completely different concept. If I remember correctly it is
hard real time.
> > I downloaded and checked 2.4.17-low-latency.patch.gz...
> > The only arch dependent part is this...
> I guess I can just try to patch my etrax kernel with this patch,
> see how much it helps.
Note: that you have to move the enabling of it from x86 specific settings.
> > The standard scheduler is preemptive but it only preempts processes
> > running in user space. The various patches handles the case of
> > long execution chains in kernel space. Like reading from a file, find
> > out that there are no free pages, trying to determine which of thousands
> > of pages to swap. Luckily :-/ most ETRAX systems does not have this
> > problem... (too few pages of RAM :-)
> You mean I shouldn't expect miracles when using low-latency patches?
They cut away the worst problems. But it does not fix areas that has not
been investigated - if you find out that you have a problem do mail
Andrew Morton he is both friendly and interested in results from other
> I fear I'll have to implement the protocol in a kernel module after all.
Maybe, but it is worth a test...