Re: Preempt Threshold Measurements

[Lee Revell]

On Tue, 2004-07-13 at 02:14, Andrew Morton wrote:
> Con Kolivas <kernel@xxxxxxxxxxx> wrote:
> >
> > Andrew Morton writes:
> > 
> > > Con Kolivas <kernel@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/