[GitHub] [activemq-artemis-native] franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass
franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass URL: https://github.com/apache/activemq-artemis-native/pull/5#issuecomment-547614074 > Isn't there a new API that would perform the proper ring operations now? Maybe, I need to check, but it would create additional compatibility issues probably, requiring very recent kernels > Also: the barrier here is part of the contract with the kernel, or is this to avoid other operations getting from this queue? With the kernel, as an example, https://github.com/apache/activemq-artemis-native/pull/5/files#diff-499e23a4fc5ac0cf8e53a85a77699575R125 prevent the processors to speculatively start reading events *before* the tail is completed to be loaded: if we drop that barrier, the processor can anticipate reading events while the kernel hasn't finished yet to write them and we will read corrupted or incomplete events. On QEMU there is a nice description of the issue: https://github.com/lowRISC/qemu/blob/master/block/linux-aio.c#L153 On https://github.com/qemu/qemu/blob/master/docs/devel/atomics.txt#L152 the description of the barrier used by them This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis-native] franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass
franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass URL: https://github.com/apache/activemq-artemis-native/pull/5#issuecomment-547614074 > Isn't there a new API that would perform the proper ring operations now? Maybe, I need to check, but it would create additional compatibility issues probably, requiring very recent kernels > Also: the barrier here is part of the contract with the kernel, or is this to avoid other operations getting from this queue? With the kernel, as an example, https://github.com/apache/activemq-artemis-native/pull/5/files#diff-499e23a4fc5ac0cf8e53a85a77699575R125 prevent the processors to speculatively start reading events *before* the tail is completed to be loaded: if we drop that barrier, the processor can anticipate reading events while the kernel hasn't finished yet to write them and we will read corrupted or incomplete events. On QEMU there is a nice description of the issue: https://github.com/lowRISC/qemu/blob/master/block/linux-aio.c#L153 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis-native] franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass
franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass URL: https://github.com/apache/activemq-artemis-native/pull/5#issuecomment-547614074 > Isn't there a new API that would perform the proper ring operations now? Maybe, I need to check, but it would create additional compatibility issues probably, requiring very recent kernels > Also: the barrier here is part of the contract with the kernel, or is this to avoid other operations getting from this queue? With the kernel, as an example, https://github.com/apache/activemq-artemis-native/pull/5/files#diff-499e23a4fc5ac0cf8e53a85a77699575R125 prevent the processors to speculatively start reading events *before* the tail is completed to be loaded: if we drop that barrier, the processor can anticipate reading events while the kernel hasn't finished yet to write them and we will read corrupted or incomplete events This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis-native] franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass
franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass URL: https://github.com/apache/activemq-artemis-native/pull/5#issuecomment-547614074 > Isn't there a new API that would perform the proper ring operations now? Maybe, I need to check, but it would create additional compatibility issues probably, requiring very recent kernels probably > Also: the barrier here is part of the contract with the kernel, or is this to avoid other operations getting from this queue? With the kernel, as an example, https://github.com/apache/activemq-artemis-native/pull/5/files#diff-499e23a4fc5ac0cf8e53a85a77699575R125 prevent the processors to speculatively start reading events *before* the tail is completed to be loaded: id we drop that barrier, the processor can anticipate reading events while the kernel hasn't finished yet to write them and we will read corrupted or incomplete events This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis-native] franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass
franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass URL: https://github.com/apache/activemq-artemis-native/pull/5#issuecomment-547614074 > Isn't there a new API that would perform the proper ring operations now? Maybe, I need to check, but it would create additional compatibility issues probably, requiring very recent kernels probably > Also: the barrier here is part of the contract with the kernel, or is this to avoid other operations getting from this queue? With the kernel, as an example, https://github.com/apache/activemq-artemis-native/pull/5/files#diff-499e23a4fc5ac0cf8e53a85a77699575R125 prevent the processors to speculatively start reading events *before* the tail is completed to be loaded: if we drop that barrier, the processor can anticipate reading events while the kernel hasn't finished yet to write them and we will read corrupted or incomplete events This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [activemq-artemis-native] franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass
franz1981 edited a comment on issue #5: ARTEMIS-2533 Support multiple architecture for ASYNCIO kernel by-pass URL: https://github.com/apache/activemq-artemis-native/pull/5#issuecomment-547575936 The issue is the reordering performed by the processor: on x86 such operation won't get reordered and we can just use memory barriers for the compilers, but power pc (like arm) does aggressive reordering and I'm not sure is ok, it can fail without being unnoticed. Indeed the Linux kernel implement the barriers for power pc in a different way then x86. The code of the ring buffer Is concurrent but with the kernel: so we need to respect the order by which the kernel is populating the ring buffer. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
