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

From: yodaiken@fsmlabs.com
Date: Mon Jan 21 2002 - 11:45:54 EST


On Mon, Jan 21, 2002 at 05:33:50PM +0100, Peter Wächtler wrote:
> yodaiken@fsmlabs.com schrieb:
> >
> > On Mon, Jan 21, 2002 at 05:05:01PM +0100, Daniel Phillips wrote:
> > > > I think of "benefit", perhaps naiively, in terms of something that can
> > > > be measured or demonstrated rather than just announced.
> > >
> > > But you see why asap scheduling improves latency/throughput *in theory*,
> >
> > Nope. And I don't even see a relationship between preemption and asap I/O
> > schedulding. What make you think that I/O threads won't be preempted by
> > other threads?
> >
>
> I/O intensive threads block early voluntarily - while CPU hogs don't.

Since the preemption patch only allows additional preemption in kernel
mode, I'm curious to know what the compute bound tasks are doing in
kernel mode. Did Linux add in-kernel matrix multiplication while
I was not looking?

> Statistically there is a higher chance, that a CPU hog gets preempted
> instead of an IO bound (that gives up the CPU in some useconds anyway)

"Statistically"? As far as I know, most I/O in Linux does not block.
When you say "statistically", you should have some analysis with clearly
stated assumptions.

>
> The next IO request is hitting the device "earlier" - instead of waiting
> for the next schedule() - that makes sense to me.
>
> With this scenario the system CPU utilization gets "bigger" for the benefit
> of "faster" IO. OTOH, seti@home needs longer to run.

Sorry. No sale.

-- 
---------------------------------------------------------
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/



This archive was generated by hypermail 2b29 : Wed Jan 23 2002 - 21:00:46 EST