[
https://issues.apache.org/jira/browse/HDDS-15684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated HDDS-15684:
-------------------------------
Description:
Just an idea to improve the OM performance.
Came across
[https://medium.com/@sgn00/triple-buffer-lock-free-concurrency-primitive-611848627a1e]
We can try to think whether we can use triple buffer to replace the current
double buffer.
The current weakness of double buffer is that we cannot swap the buffers if
there is either a read or write in progress (or there might be data
corruption). Additionally, we still uses locking although technically the Ratis
applier thread and Ozone Manager double buffer can be reduced to a single SPSC
problem which might not need any locks.
The third buffer idea will add another buffer. This would decouple the read and
writer. We can also implement the lockless implementation to improve the
performance.
Another possible improvements for the locality is to use raw array instead of
list of object references. This should improve the memory locality and
hopefully improve performance. This should not be needed after the value
objects since value objects will allow value object to act like primitives
instead of references
([https://openjdk.org/projects/valhalla/value-objects)|https://openjdk.org/projects/valhalla/value-objects]
was:
Just an idea to improve the OM performance.
Came across
[https://medium.com/@sgn00/triple-buffer-lock-free-concurrency-primitive-611848627a1e]
We can try to think whether we can use triple buffer to replace the current
double buffer.
The current weakness of double buffer is that we cannot swap the buffers if
there is either a read or write in progress (or there might be data
corruption). Additionally, we still uses locking although technically the Ratis
applier thread and Ozone Manager double buffer can be reduced to a single SPSC
problem which might not need any locks.
The third buffer idea will add another buffer. This would decouple the read and
writer. We can also implement the lockless implementation to improve the
performance.
Another possible improvements for the locality is to use raw array instead of
list of object references. This should improve the memory locality and
hopefully improve performance. This should not be needed after the value
objects since value objects will allow "value object to act like primitives
instead of references
([https://openjdk.org/projects/valhalla/value-objects)|https://openjdk.org/projects/valhalla/value-objects]
> Replace OM double buffer with triple buffer
> -------------------------------------------
>
> Key: HDDS-15684
> URL: https://issues.apache.org/jira/browse/HDDS-15684
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
>
> Just an idea to improve the OM performance.
> Came across
> [https://medium.com/@sgn00/triple-buffer-lock-free-concurrency-primitive-611848627a1e]
> We can try to think whether we can use triple buffer to replace the current
> double buffer.
> The current weakness of double buffer is that we cannot swap the buffers if
> there is either a read or write in progress (or there might be data
> corruption). Additionally, we still uses locking although technically the
> Ratis applier thread and Ozone Manager double buffer can be reduced to a
> single SPSC problem which might not need any locks.
> The third buffer idea will add another buffer. This would decouple the read
> and writer. We can also implement the lockless implementation to improve the
> performance.
> Another possible improvements for the locality is to use raw array instead of
> list of object references. This should improve the memory locality and
> hopefully improve performance. This should not be needed after the value
> objects since value objects will allow value object to act like primitives
> instead of references
> ([https://openjdk.org/projects/valhalla/value-objects)|https://openjdk.org/projects/valhalla/value-objects]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
