lkml.org 
[lkml]   [2002]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subjectlocking in sync_old_buffers
    BKL hold times in sync_old_buffers aren't good.  This is one of the last 
    places that we see millisecond-scale BKL hold times.
    0.09% 8.1% 4598us(9648us) 105us( 231us)(0.00%) 37 91.9% 8.1%
    0% sync_old_buffers+0x1c

    So, I'll ask the eternal question that plagues us all, why is the BKL
    held here? I saw some discussions referring to races prevented by BKL here:
    http://groups.google.com/groups?selm=linux.kernel.Pine.GSO.4.21.0103212354420.2632-100000%40weyl.math.psu.edu&output=gplain
    From Al:
    > Ehh... Linus, the main problem is in get_super(). Want a nice race?
    > sys_ustat() vs. sys_umount(). The former does get_super(), finds
    > struct super_block and does nothing to guarantee that it will stay.
    > Then it calls ->statfs(). In the meanwhile, you umount the thing
    > and do rmmod. Oops..

    With the addition of sb_lock and refcounting on the sb, are these races
    still there? sync_supers() and sync_unlocked_inodes() both hold sb_lock.

    If we just remove the BKL from sync_old_buffers() the long hold time
    goes from BKL to sb_lock. But, sb_lock is dropped and reacquired a few
    times in that code, so latency should be better than BKL. BKL wouldn't
    have been released except in those places where it had to drop the locks
    and sleep.

    Patch to do it is attached, but I'm not holding my breath.

    --
    Dave Hansen
    haveblue@us.ibm.com
    --- linux-2.5.8-clean/fs/buffer.c Mon Apr 22 13:45:34 2002
    +++ linux/fs/buffer.c Mon Apr 22 13:45:49 2002
    @@ -2612,10 +2612,8 @@

    static void sync_old_buffers(unsigned long dummy)
    {
    - lock_kernel();
    sync_unlocked_inodes();
    sync_supers();
    - unlock_kernel();

    for (;;) {
    struct buffer_head *bh;
    \
     
     \ /
      Last update: 2005-03-22 13:25    [W:2.343 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site