Hi, yodaiken _at_ fsmlabs.com wrote: > > > 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. The point of using semaphores is that one can sleep while holding them, whether this is forced by preemption or voluntary makes no difference. > 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. How is that changed? AFAIK inserting more schedule points does not change the behaviour of the scheduler. The niced app will still get its time. > 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. Andrew's patch requires constant audition and Andrew can't audit all drivers for possible problems. That doesn't mean Andrew's work is wasted, since it identifies problems, which preempting can't solve, but it will always be a hunt for the worst cases, where preempting goes for the general case. > 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. I am more than busy to keep it running (together with a few others, who are left) and more important I make no money of it. bye, Roman - 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/
Follow-Ups:
- Re: [2.4.17/18pre] VM and swap - it's really unusableyodaiken _at_ fsmlabs.com
- Re: [2.4.17/18pre] VM and swap - it's really unusableAndrew Morton <akpm _at_ zip.com.au>
- Re: [2.4.17/18pre] VM and swap - it's really unusableAlan Cox <alan _at_ lxorguk.ukuu.org.uk>
- Re: [2.4.17/18pre] VM and swap - it's really unusableRobert Love <rml _at_ tech9.net>
- Re: [2.4.17/18pre] VM and swap - it's really unusableyodaiken _at_ fsmlabs.com
- Re: [2.4.17/18pre] VM and swap - it's really unusableRob Landley <landley _at_ trommello.org>
- Re: [2.4.17/18pre] VM and swap - it's really unusableyodaiken _at_ fsmlabs.com
- Re: [2.4.17/18pre] VM and swap - it's really unusableRoman Zippel <zippel _at_ linux-m68k.org>
- Re: [2.4.17/18pre] VM and swap - it's really unusableyodaiken _at_ fsmlabs.com
- Prev by Date: Re: Wireless Extension - new driver API - more drivers
- Next by Date: why do i get kernel panic?
- Previous by thread: Re: [2.4.17/18pre] VM and swap - it's really unusable
- Next by thread: Re: [2.4.17/18pre] VM and swap - it's really unusable
- Indexes:[Main][Thread]