[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preemptive patch for etrax kernel?




> > 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.

> > 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 
dependancy.

> 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.

> The standard scheduler is preemtive but it only preemts 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?

I fear I'll have to implement the protocol in a kernel module after all.

Best regards,

Pieter Grimmerink