Messages in this thread | | | Subject | Re: Preempt Threshold Measurements | From | Lee Revell <> | Date | Tue, 13 Jul 2004 04:03:47 -0400 |
| |
On Tue, 2004-07-13 at 02:14, Andrew Morton wrote: > Con Kolivas <kernel@kolivas.org> wrote: > > > > Andrew Morton writes: > > > > > Con Kolivas <kernel@kolivas.org> wrote: > > >> Certainly the do_munmap and exit_mmap seem to be repeat offenders on my > > >> machine too (more the latter in my case). > > >> > > > > > > This is a false positive. Nothing is setting need_resched(), so > > > unmap_vmas() doesn't bother dropping the lock. > > > > Ok well excluding do_munmap and exit_mmap the ones that have shown up > > (some more frequently than others) are: > > > > 6ms at ksoftirqd+0x6b > > Dunno. There's an unresolved RCU dentry reaping problem, but that's > unlikely to occur within ksoftirqd context. > > > 2ms at sys_ioctl+0x47 > > uses lock_kernel() at the top level. Need to know the call trace to work > out who the offender is. rtc-debug+amlat will tell you that, because it > catches the CPU hog while it's being hoggy, rather than after it has > finished. > > > 2ms at b44_open > > Lots of udelays() inside spin_lock_irq(). This is a "don't do that", I > suspect. > > > 6ms at fget+0x28 > > Would need to see the amlat trace. > > > 2ms at write_ordered_buffers+0x37 > > reiserfs > > > 4ms at blkdev_put+0x48 > > This can run under one of two depths of lock_kernel. filemap_fdatawrite() > and filemap_fdatawait() both do cond_resched(), so this is odd. >
Reiserfs uses lock_kernel heavily, could this be related?
./include/linux/reiserfs_fs.h:/* Right now we are still falling back to (un)lock_kernel, but eventually that ./include/linux/reiserfs_fs.h:#define reiserfs_write_lock( sb ) lock_kernel() ./include/linux/reiserfs_fs.h:#define reiserfs_write_unlock( sb ) unlock_kernel()
Lee
- 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/
| |