Replies: 16 comments 7 replies
-
pollLimiter := ratelimit.New(20) // try to process collected events first This is how we limit to no more then 20 waits per second with patched code. The CPU drops to 3-5% |
Beta Was this translation helpful? Give feedback.
-
Hi @albe19029 |
Beta Was this translation helpful? Give feedback.
-
Sorry, I can't understand how this can improve experience. Watermark set limit in bytes, WakeupEvents in samples. The problem is the same - we can't control how much can we wait in time. As both this events will have notification from kernel when amount of bytes or samples will be exceeded. If there will be low events count - time can be from nanoseconds to seconds. We can't set that we want: either time has expired or the number of events has been exceeded. With the patch we want to overcome the linux kernel limitation. To wait not on poll operation, but on our user space wait operation (pollLimiter.Take()) |
Beta Was this translation helpful? Give feedback.
-
By the way there is a deadline timer for poller.Wait operation which can be set with SetDeadline. |
Beta Was this translation helpful? Give feedback.
-
As I see from linux kernel source: events count will not be changed if we will read some data in parallel, and we will be notified every n events, not when there will be less data in buffer then n events or bytes. But I think it is ok (or need to fix it in kernel if for someone it is critical). |
Beta Was this translation helpful? Give feedback.
-
Can you please take a look at this patch. I checked only for Overwritable=false option, so the code can be different for this case. |
Beta Was this translation helpful? Give feedback.
-
Being required to handle events from perf event ringbuffer with a high variance in the number of events to handle over time is always a challenge. |
Beta Was this translation helpful? Give feedback.
-
So what I do in my test - just monitor kprobe/vfs_open to get path of each opened file. If I use cilium/ebpf with version 0.13.2 I get next CPU result with this script: My ring buffer size for each CPU 512k I can't set watermark bigger as I need prediction in time, if there are events in ring buffers: with patch: I didn't checked with #1404 as it has the same limitation as Watermark, and I can set it only to 1. Think the performance will be the same. |
Beta Was this translation helpful? Give feedback.
-
Do you need working benchmark? If so, please tell me - will need some time to prepare simple benchmark test. |
Beta Was this translation helpful? Give feedback.
-
I read the following as the baseline:
What I'm missing here are tests with different value combinations for watermark and deadline without your patch. e.g.
From my point of view, the given baseline is hardly comparable with the given numbers for when a patch is applied. |
Beta Was this translation helpful? Give feedback.
-
@florianl Is my comment was unclear? Do we need watermark and deadline results without patch to continue? |
Beta Was this translation helpful? Give feedback.
-
Good day. Just wanted to ask if our problem will be fixed somehow? Just to summarize: So to work with frequent events we had to set Watermark option from 1 to 128K. With that we reduce CPU from 7.2 - 9.2% to 1.7% - 2.0%. Good fix is to add some timer (maybe in ReaderOptions option) per cpu ring, and check each ring if time has elapsed and we don't have notification from epoll. Good, but not perfect is proposed ebpf_v2.patch , but fast single ring will also don't allow read slow rings in worst case. Hope it is clear that problem exists and it is possible to fix it somehow. |
Beta Was this translation helpful? Give feedback.
-
I believe we (Datadog) want something similar. We want to set our One challenge already mentioned is one (or more) highly active CPU perf buffers can prevent us from seeing the other CPU perf buffers, because they will always be ready. We essentially need a way to ensure all CPU perf buffers are read. This likely means an API other than |
Beta Was this translation helpful? Give feedback.
-
I don't know the exact procedure in your project. But I wanted to ask whether this proposal will be accepted for improvements. And what is needed to speed up decision making. Is it possible to implement patch? |
Beta Was this translation helpful? Give feedback.
-
There is currently a discussion ongoing on Slack, how things can be improved. As a result your concern should be addressed, while it should not break things existing users of the package. |
Beta Was this translation helpful? Give feedback.
-
done here #1429 |
Beta Was this translation helpful? Give feedback.
-
In situations when we have high speed events producer, and high speed events consumer ReadInto call pr.poller.Wait function for every event. In this case our thread sleep and wakeup very often. And in our tests it consumes a lot of CPU (15%)
While creating perf.Reader it is also possible to set Watermark option, but it working bad - as it only set EPOLLIN to file descriptor when buffer will be full, and on low events count - this can be blocked for a very long time.
What is possible is to return ErrEOR if wait parameter is false. In this case we can deсide what to do. For example use ratelimit.Limiter to limit polls count per second.
ebpf.patch
Beta Was this translation helpful? Give feedback.
All reactions