On Sat, Mar 25, 2000 at 10:38:35PM -0800, David S. Miller wrote:
> Date: Sat, 25 Mar 2000 23:24:59 -0700
> From: yodaiken@fsmlabs.com
>
> The hidden assumption of the pre-emption patch is that there are kernel
> paths that take more than 500us to reach a schedule or return to user
> mode. Obviously there are such paths, but what are they and why can't they
> be fixed?
>
> Just to name a few obvious ones:
>
> 1) write(fd, buffer, SOME_LARGE_VALUE);
> 2) read(fd, buffer, SOME_LARGE_VALUE);
>
> I honestly can't think of a way in which we'd want to deal with these
> cases, except to perhaps check need_resched after or before copying
We have a non-scaling, I/O system where we copy huge
chunks of data for no reason
Problem: on large reads/writes, the kernel can spend milliseconds copying
data into kernel buffers:
Loss of responsiveness
Loss of throughput for useful work
Blow cache.
Waste memory.
Solution 1:Break the copy into multiple pieces
Blow the cache 100 times, instead of once
Potentially slow down the write significantly
Gain some responsiveness for other processes.
Solution2: reduced copy writes.
Improved responsiveness
Improved throughput
Appropriate use of modern scatter/gather I/O hardware.
Solution 2 is much harder to make work and there are interesting problems
with loss of buffer cache etc. I think that part of the intention
of kiobufs is to make solution 2 more possible although there are
other methods that can also be used instead or in combination.
But, surely
the fundamental problem here is not the absence of preemption points
in the copy -- the problem is the copy itself or at least the copy
in kernel mode. One simple solution is to reject sys_read with big
numbers and have libc do the buffer allocation and copy in user space: at
least here the costs are localized to the offending process and
we don't need any added preemption points to preempt the copy.
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.- 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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:17 EST