I did some btrfs RTFS over the weeking and I have a hard time understanding
what this code is attempting to do:
28 int btrfs_tree_lock(struct extent_buffer *eb)
29 {
30 int i;
31
32 if (mutex_trylock(&eb->mutex))
33 return 0;
34 for (i = 0; i < 512
On Mon, 2008-09-08 at 13:10 +0200, Andi Kleen wrote:
> I did some btrfs RTFS over the weeking and I have a hard time understanding
> what this code is attempting to do:
>
> 28 int btrfs_tree_lock(struct extent_buffer *eb)
> 29 {
> 30 int i;
> 31
> 32 if (mutex_trylock(&eb->m
> The idea is to try to spin for a bit to avoid scheduling away, which is
> especially important for the high levels. Most holders of the mutex
> let it go very quickly.
Ok but that surely should be implemented in the general mutex code then
or at least in a standard adaptive mutex wrapper?
-An
On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > The idea is to try to spin for a bit to avoid scheduling away, which is
> > especially important for the high levels. Most holders of the mutex
> > let it go very quickly.
>
> Ok but that surely should be implemented in the general mutex co
On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > The idea is to try to spin for a bit to avoid scheduling away, which is
> > > especially important for the high levels. Most holders of the mutex
> > > let it go very quickly.
On Mon, 8 Sep 2008 16:20:52 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > > The idea is to try to spin for a bit to avoid scheduling away, which is
> > > > especially importa
On Mon, 2008-09-08 at 08:07 -0700, Stephen Hemminger wrote:
> On Mon, 8 Sep 2008 16:20:52 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > > On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > > > The idea is to try to spin
On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> On Mon, 8 Sep 2008 16:20:52 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > > On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote:
> > > > > The idea is to try
On Mon, 8 Sep 2008 17:47:14 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> > On Mon, 8 Sep 2008 16:20:52 +0200
> > Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote:
> > >
On Mon, 2008-09-08 at 08:50 -0700, Stephen Hemminger wrote:
> On Mon, 8 Sep 2008 17:47:14 +0200
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> > > On Mon, 8 Sep 2008 16:20:52 +0200
> > > Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >
Chris Mason wrote:
My guess is that the improvement happens mostly from the first couple of tries,
not from repeated spinning. And since it is a mutex, you could even do:
I started with lower spin counts, I really didn't want to spin at all
but the current values came from trial and error.
Ex
On Mon, 2008-09-08 at 12:13 -0400, jim owens wrote:
> Chris Mason wrote:
> >> My guess is that the improvement happens mostly from the first couple of
> >> tries,
> >> not from repeated spinning. And since it is a mutex, you could even do:
> >
> > I started with lower spin counts, I really didn't
On Mon, 08 Sep 2008 12:20:32 -0400
Chris Mason <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-09-08 at 12:13 -0400, jim owens wrote:
> > Chris Mason wrote:
> > >> My guess is that the improvement happens mostly from the first couple of
> > >> tries,
> > >> not from repeated spinning. And since it is a
On Mon, Sep 08, 2008 at 09:49:42AM -0700, Stephen Hemminger wrote:
> Not to mention the problem that developers seem to have faster machines than
> average user, but slower than the enterprise and future generation CPU's.
> So any tuning value seems to get out of date fast.
So where do my fellow d
Christoph Hellwig wrote:
On Mon, Sep 08, 2008 at 09:49:42AM -0700, Stephen Hemminger wrote:
Not to mention the problem that developers seem to have faster machines than
average user, but slower than the enterprise and future generation CPU's.
So any tuning value seems to get out of date fast.
On Monday 08 September 2008 16:28:34 Chris Mason wrote:
> > People seem to repeatedly come up with adaptive mutex based on intuitive
> > hunch, and never do much analysis before or afterwards.
>
> In my case, it very easy to measure. Just watch the context switch rate
> on any metadata intensive w
On Monday 08 September 2008 18:32:14 Ric Wheeler wrote:
> Christoph Hellwig wrote:
> > On Mon, Sep 08, 2008 at 09:49:42AM -0700, Stephen Hemminger wrote:
> >> Not to mention the problem that developers seem to have faster machines
> >> than average user, but slower than the enterprise and future ge
On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> The problem is that they are a nuisance. It is impossible to choose
> the right trade off between spin an no-spin, also they optimize for
> a case that doesn't occur often enough to be justified.
>
> People seem to repeatedly com
18 matches
Mail list logo
