Optimize timestamps with per-CPU caching #2349
Conversation
|
@MorganaFuture we'be been lacking resources to implement this feature, so thank you! This is draft, we shouldn't review it yet, right? |
|
This PR is not ready yet. I'm having some difficulties running tests for Tempesta. Once I make sure everything works as expected, I will update the PR status |
|
BTW, why not simply update a per-CPU variable in a timer SoftIRQ? Then each |
MorganaFuture
force-pushed
the
morganaFuture/timestamp-optimization
branch
from
cf97fdd to
81600a9
Compare
|
@keshonok could you please take a look at changes? |
krizhanovsky
requested review from
krizhanovsky and
const-t
and removed request for
keshonok
MorganaFuture
force-pushed
the
morganaFuture/timestamp-optimization
branch
from
dc7f740 to
32f83f5
Compare
|
|
||
| /* Update the timestamp on all CPUs */ | ||
| for_each_online_cpu(cpu) { | ||
| per_cpu(tfw_ts_cache, cpu) = ts.tv_sec; |
There was a problem hiding this comment.
It looks not good, however we do it only once per second. But I have doubts about current solution anyway. Suggested in the task approach seems more elegant. We can conditionally update per-cpu cached time relying on jiffies inside softirq handler. @krizhanovsky What do you think?
There was a problem hiding this comment.
@MorganaFuture In this solution we do check/update timer on each call of tfw_current_timestamp, but we can improve it doing check/update only once per softirq handler, and then in tfw_current_timestamp only receive the value. Solution with timer also not bad, but I would prefer to minimize cache bouncing even once per second. However, maybe I'm trying to over optimize, therefore I would like to hear also your @MorganaFuture opinion as well as @krizhanovsky.
What
Implement per-CPU cached timestamp mechanism for tfw_current_timestamp()
Add automatic refresh when cached timestamp becomes stale
Only cache timestamps in softirq context
Why
ktime_get_real_ts64() is a heavyweight kernel function
Links
2275