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

    I made a small calculation of the time required to make a user-kernel
    and the amount of data have to be huge to give an impact - unless you
    up with a page fault, what will happen then? (Something sensible I
    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;
    if (!written)
    written = -EFAULT;
    mark_buffer_uptodate(bh, 1);
    } 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 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:
    > >
    > > 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:

    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.024 / U:4.788 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site