On 17-04-18 11:55 PM, Jakub Kicinski wrote:
On Tue, 18 Apr 2017 21:37:12 -0400, Jamal Hadi Salim wrote:
On 17-04-18 06:12 PM, Jakub Kicinski wrote:

[..]
I see both being fine from that perspective - you dont need 100%
accuracy. Just something that is within reason of a small delta
of time.

I'm just referring to the theoretical possibility that if the dumping
process gets preempted for long enough you may loose samples.  Just
because the dumping process cannot control when kernel executes this
line:

        jiffy_wanted = jiffies - jiffy_msecs;

It could in theory be few seconds after the request was made.  Perhaps
using timestamps from a proper time sources instead of the notion of
"last X seconds" would solve that?


Good point which i didnt mention as part of the drawbacks. This
is a tradeoff. We dont need to be 100% accurate[1].
The timestamps on the action entries in the kernel are in jiffies;
a lot simpler to do jiffy comparison. If you used a different
timestamp source you'd need to convert for every comparison you
make (i am not sure how costly is when you have many actions).

In use cases i am familiar with, there is a user process app which
opens the socket once and issues dumps every X seconds (ranging from
5-120 seconds). So we will re-issue the dump regardless. Yes
it would be an issue if said application keeps getting pre-empted
and that jiffy computation was always off - but not sure under
what circumstances that could be a common scenario.

cheers,
jamal

[1] As an example, dumps are never 100% accurate you could iterate
 something that then changes while you are in the middle of dumping
 which then renders an already dumped entity obsolete.

Reply via email to