On Tue, May 06, 2008 at 01:44:49PM +0200, Ingo Molnar wrote: > * Zhang, Yanmin <yanmin_zhang@xxxxxxxxxxxxxxx> wrote: > > After I manually reverted the patch against 2.6.26-rc1 while fixing > > lots of conflictions/errors, aim7 regression became less than 2%. > > hm, which exact semaphore would that be due to? > > My first blind guess would be the BKL - there's not much other semaphore > use left in the core kernel otherwise that would affect AIM7 normally. > The VFS still makes frequent use of the BKL and AIM7 is very VFS > intense. Getting rid of that BKL use from the VFS might be useful to > performance anyway. That's slightly slanderous to the VFS ;-) The BKL really isn't used that much any more. So little that I've gone through and produced a list of places it's used: fs/block_dev.c opening and closing a block device. Unlikely to be provoked by AIM7. fs/char_dev.c chrdev_open. Unlikely to be provoked by AIM7. fs/compat.c mount. Unlikely to be provoked by AIM7. fs/compat_ioctl.c held around calls to ioctl translator. fs/exec.c coredump. If this is a contention problem ... fs/fcntl.c held around call to ->fasync. fs/ioctl.c held around f_op ->ioctl call (tmpfs doesn't have ioctl). ditto bmap. there's fasync, as previously mentioned. fs/locks.c hellhole. I hope AIM7 doesn't use locks. fs/namespace.c mount, umount. Unlikely to be provoked by AIM7. fs/read_write.c llseek. tmpfs uses the unlocked version. fs/super.c shtdown, remount. Unlikely to be provoked by AIM7. So the only likely things I can see are: - file locks - fasync -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
