On Tue, 10 Apr 2001 yodaiken@fsmlabs.com wrote:
> On Tue, Apr 10, 2001 at 09:08:16PM -0700, Paul McKenney wrote:
> > > Disabling preemption is a possible solution if the critical section is
> > short
> > > - less than 100us - otherwise preemption latencies become a problem.
> >
> > Seems like a reasonable restriction. Of course, this same limit applies
> > to locks and interrupt disabling, right?
>
> So supposing 1/2 us per update
> lock process list
> for every process update pgd
> unlock process list
>
> is ok if #processes < 200, but can cause some unspecified system failure
> due to a dependency on the 100us limit otherwise?
Only to a hard real-time system.
> And on a slower machine or with some heavy I/O possibilities ....
I'm mostly interested in Linux in embedded systems, where we have a lot
of control over the overall system, such as how many processes are
running. This makes it easier to control latencies than on a
general purpose computer.
> We have a tiny little kernel to worry about inRTLinux and it's quite
> hard for us to keep track of all possible delays in such cases. How's this
> going to work for Linux?
The same way everything works for Linux: with enough people around the
world interested in and working on these problems, they will be fixed.
Nigel Gamble nigel@nrg.org
Mountain View, CA, USA. http://www.nrg.org/
MontaVista Software nigel@mvista.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:15 EST