[PATCH] Adaptive spinning for lockmgr
Attilio Rao
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
_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-smp
To unsubscribe, send any mail to "freebsd-smp...@freebsd.org"
Kris Kennaway
> 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
Attilio Rao
> 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
Kris Kennaway
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