lkml.org 
[lkml]   [2002]   [Jan]   [29]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
Messages in this thread
    /
    DateTue, 29 Jan 2002 17:26:41 -0800
    FromAndrew Morton <>
    SubjectRe: [PATCH] 2.5: push BKL out of llseek
    Robert Love wrote:
    > 
    > @@ -84,9 +84,9 @@
    >         fn = default_llseek;
    >         if (file->f_op && file->f_op->llseek)
    >                 fn = file->f_op->llseek;
    > -       lock_kernel();
    > +       down(&file->f_dentry->d_inode->i_sem);
    >         retval = fn(file, offset, origin);
    > -       unlock_kernel();
    > +       up(&file->f_dentry->d_inode->i_sem);
    >         return retval;
    >  }
    
    Just a little word of caution here.  Remember the
    apache-flock-synchronisation fiasco, where removal
    of the BKL halved Apache throughput on 8-way x86.
    
    This was because the BKL removal turned serialisation
    on a quick codepath from a spinlock into a schedule().
    
    So...  I'd suggest that changes such as this should be
    benchmarked in isolation; otherwise we end up spending
    quite some time hunting down mysterious reports of
    performance regression, and having to rethink stuff.
    
    And llseek is *fast*.  If we're seeing significant
    lock contention in there then adding a schedule() is
    likely to turn Anton into one unhappy dbencher.
    
    -
    -
    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/
    
    
    \
     
     \ /
      Last update: 2005-03-22 13:15    [from the cache]
    ©2003-2008