[PATCH] Adaptive spinning for lockmgr

[Attilio Rao-2]

This patch enables adaptive spinning for lockmgr:
http://www.freebsd.org/~attilio/adaptive_lockmgr.diff

and it should presumably improve performance on disks/vfs/buffer cache
based benchmarks, so, if you want to try out and report any benchmarks
result, I'd love to see it.
Please note that there are some parameters to tune: for example, you
would like to not enable adaptive spinning to default while you just
want that for a class of locks (and in that case you want to apply the
reversed logic for what is living now) or you want to use different
values  for retries and loops. Interested developers can refer to such
3 variables.
Peter Holm alredy tested that patch for about 24hours without any
regression to report.

Also note that the patch is not 100% yet as long as it needs UPDATES
and manpages updates, but they will be added just in time before to
commit.
The modify is all there.

Thanks,
Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-smp@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-smp
To unsubscribe, send any mail to "freebsd-smp-unsubscribe@..."

[Kris Kennaway-3]

Attilio Rao wrote:

> This patch enables adaptive spinning for lockmgr:
> http://www.freebsd.org/~attilio/adaptive_lockmgr.diff
>
> and it should presumably improve performance on disks/vfs/buffer cache
> based benchmarks, so, if you want to try out and report any benchmarks
> result, I'd love to see it.
> Please note that there are some parameters to tune: for example, you
> would like to not enable adaptive spinning to default while you just
> want that for a class of locks (and in that case you want to apply the
> reversed logic for what is living now) or you want to use different
> values  for retries and loops. Interested developers can refer to such
> 3 variables.
> Peter Holm alredy tested that patch for about 24hours without any
> regression to report.
>
> Also note that the patch is not 100% yet as long as it needs UPDATES
> and manpages updates, but they will be added just in time before to
> commit.
> The modify is all there.

I have a vague memory that we had tested a version of this in the past
and found that it caused a performance loss in common cases?  Many
lockmgr callers are not amenable to adaptive spinning because they have
to wait on slow I/O.  Testing only with e.g. md backing might give
results that are non-representative.

Kris
_______________________________________________
freebsd-smp@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-smp
To unsubscribe, send any mail to "freebsd-smp-unsubscribe@..."

[Attilio Rao-2]

2009/6/14 Kris Kennaway <kris@...>:

> Attilio Rao wrote:
>>
>> This patch enables adaptive spinning for lockmgr:
>> http://www.freebsd.org/~attilio/adaptive_lockmgr.diff
>>
>> and it should presumably improve performance on disks/vfs/buffer cache
>> based benchmarks, so, if you want to try out and report any benchmarks
>> result, I'd love to see it.
>> Please note that there are some parameters to tune: for example, you
>> would like to not enable adaptive spinning to default while you just
>> want that for a class of locks (and in that case you want to apply the
>> reversed logic for what is living now) or you want to use different
>> values  for retries and loops. Interested developers can refer to such
>> 3 variables.
>> Peter Holm alredy tested that patch for about 24hours without any
>> regression to report.
>>
>> Also note that the patch is not 100% yet as long as it needs UPDATES
>> and manpages updates, but they will be added just in time before to
>> commit.
>> The modify is all there.
>
> I have a vague memory that we had tested a version of this in the past and
> found that it caused a performance loss in common cases?  Many lockmgr
> callers are not amenable to adaptive spinning because they have to wait on
> slow I/O.  Testing only with e.g. md backing might give results that are
> non-representative.

I don't think I ever implemented adaptive spinning in lockmgr so if
somebody else did I don't know. Said that, probabilly the best
approach would be to disable it by default ad use a LK_ADAPTIVESPIN
flag on a per instance basis.
Such conditions, though, need to be explored a bit and I have no time
to dedicate to this right now.

Thanks,
Attilio


--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-smp@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-smp
To unsubscribe, send any mail to "freebsd-smp-unsubscribe@..."

[Kris Kennaway-3]

Attilio Rao wrote:

> 2009/6/14 Kris Kennaway <kris@...>:
>> Attilio Rao wrote:
>>> This patch enables adaptive spinning for lockmgr:
>>> http://www.freebsd.org/~attilio/adaptive_lockmgr.diff
>>>
>>> and it should presumably improve performance on disks/vfs/buffer cache
>>> based benchmarks, so, if you want to try out and report any benchmarks
>>> result, I'd love to see it.
>>> Please note that there are some parameters to tune: for example, you
>>> would like to not enable adaptive spinning to default while you just
>>> want that for a class of locks (and in that case you want to apply the
>>> reversed logic for what is living now) or you want to use different
>>> values  for retries and loops. Interested developers can refer to such
>>> 3 variables.
>>> Peter Holm alredy tested that patch for about 24hours without any
>>> regression to report.
>>>
>>> Also note that the patch is not 100% yet as long as it needs UPDATES
>>> and manpages updates, but they will be added just in time before to
>>> commit.
>>> The modify is all there.
>> I have a vague memory that we had tested a version of this in the past and
>> found that it caused a performance loss in common cases?  Many lockmgr
>> callers are not amenable to adaptive spinning because they have to wait on
>> slow I/O.  Testing only with e.g. md backing might give results that are
>> non-representative.
>
> I don't think I ever implemented adaptive spinning in lockmgr so if
> somebody else did I don't know. Said that, probabilly the best
> approach would be to disable it by default ad use a LK_ADAPTIVESPIN
> flag on a per instance basis.
> Such conditions, though, need to be explored a bit and I have no time
> to dedicate to this right now.

OK, I am mis-remembering then.  Ideally it would be tested in several
representative workloads to see where it helps.  I can't promise whether
I can do this though, for the same reason as you :(

Kris
_______________________________________________
freebsd-smp@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-smp
To unsubscribe, send any mail to "freebsd-smp-unsubscribe@..."