[lkml]   [2000]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] preemptive kernel, preemptive-2.3.52-A7
    On Sat, Mar 25, 2000 at 10:38:35PM -0800, David S. Miller wrote:
    > Date: Sat, 25 Mar 2000 23:24:59 -0700
    > From:
    > 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 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.021 / U:34.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site