Re: [2.4.17/18pre] VM and swap - it's really unusable

[yodaiken _at_ fsmlabs.com]

On Sat, Jan 12, 2002 at 12:53:06PM +0100, Roman Zippel wrote:
> Hi,
> 
> yodaiken _at_ fsmlabs.com wrote:
> 
> > I believe that the preempt path leads inexorably to
> > mutex-with-stupid-priority-trick and that would be very unfortunate indeed.
> > It's unavoidable because sooner or later someone will find that preempt +
> > SCHED_FIFO leads to
> >                 niced app 1 in K mode gets Sem A
> >                 SCHED_FIFO app prempts and blocks on  Sem A
> >                 whoops! app 2 in K more preempts niced app 1
> 
> Please explain what's different without the preempt patch.

See that "preempt" in line 2 . Linux does not
preempt kernel mode processes otherwise. The beauty of the
non-preemptive kernel is that "in K mode every process makes progress"
and even the "niced app" will complete its use of SemA and 
release it in one run. If you have a reasonably fair scheduler you
can make very useful analysis with Linux now of the form

	Under 50 active proceses in the system means that in every
	2 second interval every process
	will get at least 10ms of time to run.

That's a very valuable property and it goes away in a preemptive kernel 
to get you something vague.


> 
> >         Hey my DVD player has stalled, lets add sem_with_revolting_priority_trick!
> >         Why the hell is UP Windows XP3 blowing away my Linux box on DVD playing while
> >         Linux now runs with the grace and speed of IRIX?
> 
> Because the IRIX implementation sucks, every implementation has to suck?
> Somehow I have the suspicion you're trying to discourage everyone from
> even trying, because if he'd succeeded you'd loose a big chunk of
> potential RTLinux customers.

So your argument is that I'm advocating Andrew Morton's patch which 
reduces latencies more than the preempt patch because I have a
financial interest in not reducing latencies? Subtle.

In any case, motive has no bearing on a technical argument. 
Your motive could be to make the 68K look better by reducing 
performance on other processors for all I know. 

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/