On Fri, Aug 31, 2007 at 05:09:21PM +0200, Peter Zijlstra wrote:
> On Sat, 2007-09-01 at 01:05 +1000, David Chinner wrote:
>
> > > Trouble is, we'd like to have a sane upper bound on the amount of held
> > > locks at any one time, obviously this is just wanting, because a lot of
> > > lock chains a
On Fri, Aug 31, 2007 at 05:09:21PM +0200, Peter Zijlstra wrote:
> On Sat, 2007-09-01 at 01:05 +1000, David Chinner wrote:
>
> > > Trouble is, we'd like to have a sane upper bound on the amount of held
> > > locks at any one time, obviously this is just wanting, because a lot of
> > > lock chains a
Peter Zijlstra wrote:
> On Sat, 2007-09-01 at 01:05 +1000, David Chinner wrote:
>
>>> Trouble is, we'd like to have a sane upper bound on the amount of held
>>> locks at any one time, obviously this is just wanting, because a lot of
>>> lock chains also depend on the number of online cpus...
>> Su
On Sat, 2007-09-01 at 01:05 +1000, David Chinner wrote:
> > Trouble is, we'd like to have a sane upper bound on the amount of held
> > locks at any one time, obviously this is just wanting, because a lot of
> > lock chains also depend on the number of online cpus...
>
> Sure - this is an obvious
On Fri, Aug 31, 2007 at 04:33:51PM +0200, Peter Zijlstra wrote:
> On Fri, 2007-08-31 at 23:50 +1000, David Chinner wrote:
> > On Fri, Aug 31, 2007 at 08:39:49AM +0200, Peter Zijlstra wrote:
> > > On Thu, 2007-08-30 at 23:43 -0500, Eric Sandeen wrote:
> > > > The xfs filesystem can exceed the curren
On Fri, 2007-08-31 at 09:33 -0500, Eric Sandeen wrote:
> Peter, unless there is some other reason to do so, changing xfs
> performance behavior simply to satisfy lockdep limitations* doesn't seem
> like the best plan.
>
> I suppose one slightly flakey option would be for xfs to see whether
> lock
David Chinner wrote:
> On Fri, Aug 31, 2007 at 08:39:49AM +0200, Peter Zijlstra wrote:
>> On Thu, 2007-08-30 at 23:43 -0500, Eric Sandeen wrote:
>>> The xfs filesystem can exceed the current lockdep
>>> MAX_LOCK_DEPTH, because when deleting an entire cluster of inodes,
>>> they all get locked in x
On Fri, 2007-08-31 at 23:50 +1000, David Chinner wrote:
> On Fri, Aug 31, 2007 at 08:39:49AM +0200, Peter Zijlstra wrote:
> > On Thu, 2007-08-30 at 23:43 -0500, Eric Sandeen wrote:
> > > The xfs filesystem can exceed the current lockdep
> > > MAX_LOCK_DEPTH, because when deleting an entire cluster
On Fri, Aug 31, 2007 at 08:39:49AM +0200, Peter Zijlstra wrote:
> On Thu, 2007-08-30 at 23:43 -0500, Eric Sandeen wrote:
> > The xfs filesystem can exceed the current lockdep
> > MAX_LOCK_DEPTH, because when deleting an entire cluster of inodes,
> > they all get locked in xfs_ifree_cluster(). The
On Thu, 2007-08-30 at 23:43 -0500, Eric Sandeen wrote:
> The xfs filesystem can exceed the current lockdep
> MAX_LOCK_DEPTH, because when deleting an entire cluster of inodes,
> they all get locked in xfs_ifree_cluster(). The normal cluster
> size is 8192 bytes, and with the default (and minimum)
10 matches
Mail list logo