Messages in this thread | | | Date | Sat, 12 Jan 2002 05:28:02 -0700 | From | yodaiken@fsmlabs ... | Subject | Re: [2.4.17/18pre] VM and swap - it's really unusable |
| |
On Sat, Jan 12, 2002 at 12:53:06PM +0100, Roman Zippel wrote: > Hi, > > yodaiken@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |