On Mon, Aug 30, 1999 at 11:45:54AM +0200, Ingo Molnar wrote:
>
> On Mon, 30 Aug 1999 yodaiken@chelm.cs.nmt.edu wrote:
>
> > It absolutely is something new. In the current kernel, we check for
> > preemption only at points where we are about to do a context
> > switch anyways [...]
>
> huh? We have a preemption point after every system call. Typically we
> execute tens of thousands of system calls per second on a moderately
> loaded system, and only tens/hundreds of context switches per second. A
> system call is not a context switch. I dont really see where this
> discussion is going to. If you believe there is something weird going on,
> please download the patch and prove it. The only thing that 'changed' is
> the behavior of high-frequency-rescheduling RT tasks, but this is very
> much intended.
>
> > That is the logic is:
> > before commit to a switch to user, see
> > if there is a hint to call the scheudler
>
> sorry, a switch to user-space is nowhere near a context switch. A context
> switch is when we schedule from one process (thread) to another one. There
> is about an order of magnitude between the cost of them, and about two
> orders of magnitude between the typical frequency of them. (user-kernel
> entries being much cheaper and much more frequent)
>
> > This is not the same as
> > before copy a block check to see if there
> > is a hint to call the scheduler.
>
> we have thousands of system calls executed between every typical
> reschedule. Go check it yourself. So wether one out of those final system
> calls is 'partial' or not makes no difference. If it makes a difference
> then the patch has unearthed some kernel bug which we want to fix anyway.
>
> > > [btw. 99% of the time the X client gets rescheduled is not due to
> > > need_resched but due to the unix-domain socket buffer running out of write
> > > space. And this is true globally, need_resched itself is resposible for a
> > > small fraction of reschedules only.]
> >
> > In the current system, yes. After your patch, it is not at all clear.
>
> huh? it is absolutely true both for the current kernel and for the patched
> kernel. The patch does not generate _any_ new need_resched 'events'. It
> only shortens the time we 'respond' to need_resched, thats all.
> need_resched is rarely used in a typical (or benchmarked) system, whenever
> some process is trying to naturally preempt a currently running process.
>
> if you think about it, many 'need_resched events' can happen at a large
> scale only if there is a higher-statical-priority (not necesserily RT)
> process around that does high frequency rescheduling. Nothing in a typical
> system does that - and if it does than the priority difference very much
> mandates the kernel to reschedule ASAP. In fact, with the patch i see much
> better interactive behavior under X when i load the system, interactive
> events (which have higher priority) get executed much faster.
>
> -- mingo
>
> --- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
> echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
> ----
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/~rtlinux/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/