Messages in this thread | | | Date | Mon, 21 Jan 2002 18:12:58 +0100 | From | Peter Wächtler <> | Subject | Re: [2.4.17/18pre] VM and swap - it's really unusable |
| |
yodaiken@fsmlabs.com schrieb: > > 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? >
Dead right you are. Then there are only slow system calls left. Umh, execve(), fork() (with big address space) - what about page_launder etc.?
> > 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.
You mean, the syscall returns without a reschedule? Aehm, now it's time for some statistics where the kernel spents its time on ;-)
But what is a possible explanation for the people, who think their systems behave better with preemption - strong believe? - 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/
| |