lkml.org 
[lkml]   [2000]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectext2 retry code (Was: Re: [patch] preemptive kernel, preemptive-2.3.52-A7)
    Hi,

    I made a small calculation of the time required to make a user-kernel
    copy
    and the amount of data have to be huge to give an impact - unless you
    end
    up with a page fault, what will happen then? (Something sensible I
    guess,
    like rescheduling during IO, but while reading code I found this)


    from ext2/file.c(280..307) linux-2.2.13
    interesting lines marked (a)..(d)

    /* Tricky: what happens if we are writing the complete
    * contents of a block which is not currently
    * initialised? We have to obey the same
    * synchronisation rules as the IO code, to prevent some
    * other process from stomping on the buffer contents by
    * refreshing them from disk while we are setting up the
    * buffer. The copy_from_user() can page fault, after
    * all. We also have to throw away partially successful
    * copy_from_users to such buffers, since we can't trust
    * the rest of the buffer_head in that case. --sct */

    (a) new_buffer = (!buffer_uptodate(bh) && !buffer_locked(bh) &&
    c == sb->s_blocksize);

    (b) if (new_buffer) {
    set_bit(BH_Lock, &bh->b_state);
    (c) c -= copy_from_user (bh->b_data + offset, buf, c);
    (d) if (c != sb->s_blocksize) {
    c = 0;
    unlock_buffer(bh);
    brelse(bh);
    if (!written)
    written = -EFAULT;
    break;
    }
    mark_buffer_uptodate(bh, 1);
    unlock_buffer(bh);
    } else {


    (a) Only buffers with "c == sb->s_blocksize" can be new_buffers
    (b) Test for new buffers
    (c.1) copy_from_user(..., c) will return c won't it???
    (c.2) c -= c gives c = 0
    (d) if (c != sb->s_blocksize) ALWAYS true
    and the buffer gets thrown away...
    (d') should not the test be "if (c != 0) then" to catch partial copies

    /RogerL


    yodaiken@fsmlabs.com wrote:
    >
    > 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.
    >
    >
    > - - -

    --
    Home page:
    http://www.norran.net/nra02596/

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

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