> On Sat, 25 May 2002, Oliver Xymoron wrote:
> >
> > I'm sure you know this route is not very useful - there's practically
> > nothing that we can push across the hard RT divide anyway. We can't do
> > meaningful filesystem I/O, memory allocation, networking, or VM fiddling -
> > what's left?
>
> Atomic memory allocation, for one. Potentially very useful.
Dunno. That implies reservations on the Linux side - generally RT apps
are going to be sensitive to memory exhaustion. Given that, it's easier
just to budget for them all up front and carve that memory out at boot.
Not that I'm against a reservation scheme. I've been arguing for one for
a while to avoid deadlocks with network storage.
> > Cleaning up soft RT latencies will make the vast majority of people who
> > think they want hard RT happy anyway.
>
> I certainly personally agree with you, but the hard-liners don't.
Making subsystems of the kernel RT-safe won't buy much for them and won't
help latencies. The people who would want you to do that are from the
buzzword camp.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- 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/