lkml.org 
[lkml]   [2005]   [Mar]   [14]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 13 Mar 2005 21:12:34 -0800
FromAndrew Morton <>
SubjectRe: inode_lock heavily contended in 2.6.11
Peter Chubb <peterc@gelato.unsw.edu.au> wrote:
>
> 
> When running reaim7 on a 12-way IA64 on an ext2 filesystem on a ram
> disc, I see very heavy contention on inode_lock.

Yes, that's a big global lock, protecting global resources.  I always
expected it to hit someone's fan, but it never did.

> lockstat output shows:
> 
> SPINLOCKS         HOLD            WAIT
>   UTIL  CON    MEAN(  MAX )   MEAN(  MAX )(% CPU)     TOTAL NOWAIT SPIN RJECT  NAME
>  46.8% 52.4%  1.9us( 130us)   20us(8073us)(21.5%)   5072151 47.6% 52.4%    0%  inode_lock
>  15.9% 59.5%  3.8us(  61us)   18us(7067us)( 3.9%)    852983 40.5% 59.5%    0%    __sync_single_inode+0xf0
>   9.2% 59.0%  1.2us(  25us)   20us(8073us)( 7.8%)   1596487 41.0% 59.0%    0%    generic_osync_inode+0xe0
> 
>  (etc).
> 
> Is anyone else seeing this on more realistic workloads?

An fsync/O_SYNC-intensive workload on a ram disk is likely to bring it out,
yes.  But once one has real disks under there, the acquisition frequency
will fall a lot.

Unless people are being all shy again, I don't think anyone has hit
significant inode_lock problems on more real-world things.

-
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/

\
 
 \ /
  Last update: 2005-03-22 14:11    [from the cache]
©2003-2008