Messages in this thread Patch in this message | | | Date | Tue, 16 Nov 2004 10:28:59 -0600 | From | Robin Holt <> | Subject | Re: 21 million inodes is causing severe pauses. |
| |
On Mon, Nov 15, 2004 at 02:57:14PM -0800, Andrew Morton wrote: > Robin Holt <holt@sgi.com> wrote: > > > > One significant problem we are running into is autofs trying to umount the > > file systems. This results in the umount grabbing the BKL and inode_lock, > > holding it while it scans through the inode_list and others looking for > > inodes used by this super block and attempting to free them. > > You'll need invalidate_inodes-speedup.patch and > break-latency-in-invalidate_list.patch (or an equivalent). >
I added the break-latency-in-invalidate_list.patch to the SLES9 kernel. I am running the test again, but do not see how that change can do anything to eliminate the race condition which appears to leave me with a NULL pointer. I will dig into that more today if other obligations allow it.
> That'll get you most of the way, but the BKL will still be a problem. > > Removing lock_kernel() in the umount path is probably a major project so > for now, you can just drop and reacquire it by doing > release_kernel_lock()/reacquire_kernel_lock() around invalidate_inodes().
I guess I am very concerned at this point. If I can do a release/reacquire, why not just change generic_shutdown_super() so the lock_kernel() does not happen until the first pass has occurred. ie:
--- super.c.orig 2004-11-16 10:22:17 -06:00 +++ super.c 2004-11-16 10:22:41 -06:00 @@ -232,10 +232,10 @@ dput(root); fsync_super(sb); lock_super(sb); - lock_kernel(); sb->s_flags &= ~MS_ACTIVE; /* bad name - it should be evict_inodes() */ invalidate_inodes(sb); + lock_kernel();
if (sop->write_super && sb->s_dirt) sop->write_super(sb); This at least makes the lock_kernel time much smaller than it is right now. It also does not affect any callers that may really need the BKL.
I guess I am really asking for an indication of what the BKL is supposed to be protecting. I have not dug for the intent down the VFS code paths at all. - 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/
| |