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

Re: Preemptive patch for etrax kernel?

On onsdagen den 3 april 2002 11.02, Pieter Grimmerink wrote:
> > On Tue, 2 Apr 2002, Pieter Grimmerink wrote:
> > > What would be the chances of getting a preemptive schedular patch
> > > working on the etrax kernel?
> > > Has anyone ever tried this, or can anyone predict what would
> > > be necessary to port any of the available patches?
> >
> > If you say what you're going to use it for, maybe we or others on
> > the list
> > can recommend other ways than trying those patches.
> 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.


What will the problem be if it takes 10 ms? 100 ms?
10 ms should be achievable with Mortons patch on 100 MHz CPU.

Note: your process that has to be responsible has to have SCHED_FIFO
or SCHED_RR scheduling class otherwise it could stay in queue for
quite some time... And it might be a good idea to lock the processes pages
in memory - but you have to be root to do this.

for example code see 
  but you do not need the max value, any will do... (there are usually
  no more RT processes in the system)
and for some history (starting with kernel 2.2 days)...

> I fear the standard linux kernel will not be responsive enough, and I'd
> rather not have to implement much of the protocol in a kernelmodule in
> order to be able to respond in time.
> 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?

(Here you have the "don't do that" list too)

I downloaded and checked 2.4.17-low-latency.patch.gz...
The only arch dependent part is this...
--- linux-2.4.18-pre1/arch/i386/config.in	Fri Dec 21 11:19:13 2001
+++ linux-akpm/arch/i386/config.in	Sat Jan  5 11:35:36 2002
@@ -26,6 +26,9 @@ endmenu

 mainmenu_option next_comment
 comment 'Processor type and features'
+bool 'Low latency scheduling' CONFIG_LOLAT
+dep_bool 'Control low latency with sysctl' CONFIG_LOLAT_SYSCTL $CONFIG_LOLAT
 choice 'Processor family' \
 	"386					CONFIG_M386 \
 	 486					CONFIG_M486 \

And it is "wrong" since nothing else is arch dependent.
"In the 2.4.1 patch, Low-latency was removed from the config for other 
architectures.  It should work OK, but I can't test it.  Drop me a note if 
you want to experiment with this." - Andrew Morton

(Some of the preemption bugs that were arch specific has been
 corrected in the later kernels - I do not know if ETRAX has/had these
 problems or not. You might also notice that Reiserfs get some
 changes in this code. So ext2 and Reiserfs are checked handled
 but not JFFS2 - since this is used on embedded systems and
 embedded systems are the most likely to care about latency, this
 should be checked...)

> So I was hoping a preemptive schedular might already provide enough
> responsiveness for such applications.

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 :-)


Roger Larsson