[PATCH] D26232: [XRay][compiler-rt] XRay Buffer Queue

Serge Rogatch via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 15 08:06:45 PST 2016


rSerge added inline comments.


================
Comment at: lib/xray/CMakeLists.txt:9
+
+set(XRAY_FDR_SOURCES
+  xray_buffer_queue.cc)
----------------
Can here be a comment on what FDR is?


================
Comment at: lib/xray/tests/unit/buffer_queue_test.cc:20
+
+TEST(BufferQueueTest, API) { BufferQueue Buffers(getpagesize(), 10); }
+
----------------
Here http://man7.org/linux/man-pages/man2/getpagesize.2.html they say "Portable applications should employ sysconf(_SC_PAGESIZE) instead of getpagesize():".
Also, AFAIK, page sizes can be large (gigabytes). Would this code work then?


================
Comment at: lib/xray/xray_buffer_queue.cc:24
+  for (auto &Buf : Buffers) {
+    void *Tmp = malloc(BufferSize);
+    Buf.Buffer = Tmp;
----------------
Why not to do just 1 `malloc` and then distribute the pointers with offsets?


================
Comment at: lib/xray/xray_buffer_queue.cc:32
+std::error_code BufferQueue::getBuffer(Buffer &Buf) {
+  if (Finalizing.load(std::memory_order_acquire))
+    return std::make_error_code(std::errc::state_not_recoverable);
----------------
Shouldn't this be checked inside the mutex lock?


================
Comment at: lib/xray/xray_buffer_queue.cc:46
+  std::lock_guard<std::mutex> Guard(Mutex);
+  Buffers.push_back(Buf);
+  Buf.Buffer = nullptr;
----------------
You are making it a queue, so the least recently used memory region is popped. This is bad for CPU cache. Why not to make it a stack, so that the most recently used buffer is returned first?
It needs just a change to `push_front` here... and perhaps renaming the data structure.


https://reviews.llvm.org/D26232





More information about the llvm-commits mailing list