Re: Usefulness of xt_recent's "last seen" and "oldest_pkt" on a tickless system

Re: Usefulness of xt_recent's "last seen" and "oldest_pkt" on a tickless system

[Jan Engelhardt]

>are just a count of the number of jiffies since boot. However, on a 
>tickless kernel, there is really no well defined number of jiffies per 
>second as far as I can tell

You might want to have a look at
static void tick_do_update_jiffies64(ktime_t now) in
kernel/time/tick-sched.c ;-)

Re: Usefulness of xt_recent's "last seen" and "oldest_pkt" on a tickless system

[David Hagood]

On 01/11/2015 04:23 AM, Jan Engelhardt wrote:
>
>> are just a count of the number of jiffies since boot. However, on a
>> tickless kernel, there is really no well defined number of jiffies per
>> second as far as I can tell
>
> You might want to have a look at
> static void tick_do_update_jiffies64(ktime_t now) in
> kernel/time/tick-sched.c ;-)
>

Thanks for the reply - at least now I know somebody is listening.

However, I looked over the function in question, and it does not seem to 
address my points:

1) It's a kernel only function. I am concerned about access from user space.
2) By inspection, my machine is running a jiffies per second value that 
varies between 2145 and 2150 jiffies per second (computed by reading the 
jiffies value from /proc/stat and reading the time since boot in 
seconds). There's simply no way to use a number with that much 
variability to compute when a packet was received - there has to be some 
way to know what the conversion was at the time the packet was logged, 
not at the current time. (and according to the configuration for the 
kernel, the nominal HZ value should be 1000, but full tickless mode is 
enabled - so that value does not seem to be used.)

Re: Usefulness of xt_recent's "last seen" and "oldest_pkt" on a tickless system

[Jan Engelhardt]

On Sunday 2015-01-11 16:52, David Hagood wrote:
> On 01/11/2015 04:23 AM, Jan Engelhardt wrote:
>>
>>> are just a count of the number of jiffies since boot. However, on a
>>> tickless kernel, there is really no well defined number of jiffies per
>>> second as far as I can tell
>>
>> You might want to have a look at
>> static void tick_do_update_jiffies64(ktime_t now) in
>> kernel/time/tick-sched.c ;-)
>
>I looked over the function in question, and it does not seem to
>address my points.

>there has to be some way to know what the conversion was at the time
>the packet was logged

Let me highlight the places in tick-sched.c:

	delta = ktime_sub(now, last_jiffies_update);
	ticks = ktime_divns(delta, incr);
	do_timer(++ticks);

jiffies gets incremented by as much as time has elapsed, which means
there is a linear mapping between monotonic time and jiffies, even
though the timer interrupts themselves can occur aperiodically.

And I would expect that (the other million LoC) were written such
that even after a long tickless period - IIRC davem was able to let
the timer not tick in excess of 30 minutes - an incoming event would
cause an update of jiffies before using the value, such as in the
network receive path (skbs may be timestamped here).


: 2) By inspection, my machine is running a jiffies
>per second value that varies between 2145 and 2150 jiffies per
>second from /proc/stat

/proc/stat contains no jiffies counter in 3.19, at least not that
I can spot.

The jifs/sec is set by CONFIG_HZ, for which a common kernel only
offers the compile-time choices of 100, 250, 300, 1000, not 2150.
If you find a value of 2150, you are probably looking at the wrong
value, or have a heavily modified custom kernel.


>1) It's a kernel only function. I am concerned about access from user space.
>(computed by reading the jiffies value

TTBONK, there is no reliable way for userspace to tell the value of
CONFIG_HZ, so yes, _showing_ jiffies in /proc/net/xt_recent is
useless - but at least you can compare the numbers against each other
(not that that seems useful, either).

Re: Usefulness of xt_recent's "last seen" and "oldest_pkt" on a tickless system

[David Hagood]

On 01/11/2015 12:49 PM, Jan Engelhardt wrote:
> The jifs/sec is set by CONFIG_HZ, for which a common kernel only
> offers the compile-time choices of 100, 250, 300, 1000, not 2150.
> If you find a value of 2150, you are probably looking at the wrong
> value, or have a heavily modified custom kernel.
Nope. Standard Ubuntu 14.04 low latency kernel. And the value is 
computed by looking at the btime field in /proc/timer_list (not 
/proc/stat - my bad). Moreover, I can tell by causing a packet to be 
logged at a known time in a xt_recent rule, looking at the last_seen 
field, and then computing the ratio of the known time expressed as 
seconds since boot, and in jiffies from the kernel.

>
> TTBONK, there is no reliable way for userspace to tell the value of
> CONFIG_HZ, so yes, _showing_ jiffies in /proc/net/xt_recent is
> useless - but at least you can compare the numbers against each other
> (not that that seems useful, either).
>

Agreed.

Usefulness of xt_recent's "last seen" and "oldest_pkt" on a tickless system

[David Hagood]

First of all, this is about the third time I've asked about this subject 
on this mailing list, and I've never had anybody reply.
/taps microphone
Is this thing on?

I have been trying for several months to work out a way to parse the the 
output of "cat /proc/net/xt_recent/<name of rule>", and return 
meaningful numbers for the "last_seen" and "oldest_pkt" fields. As best 
as I can determine, these are just a count of the number of jiffies 
since boot. However, on a tickless kernel, there is really no well 
defined number of jiffies per second as far as I can tell - it's going 
to be a function of how often things need the system to wake up, and 
will vary from moment to moment based upon the workload of the system.

If this is so, then this calls into question the utility of reporting 
jiffies to the user - there's no way the user has to relate those values 
to anything meaningful. It also calls into question the whole idea that 
a recent rule can meaningfully specify a number of seconds for a packet 
to be tested, if all that is stored is a number of jiffies.

So, the first question I have is: is there any meaningful way a 
userspace tool can convert the values reported by /proc/net/xt_recent/* 
into a wall clock time?

The second question is: if the answer to the first question is no, then 
why report those values at all? The whole point of a procfile interface 
is to report data to userspace, but if there is no meaningful way to use 
that information, what good is it?

The third question is: wouldn't make more sense to capture the actual 
wall-clock time of a packet, and report that to user space in a 
meaningful way from the procfile interface? At least report time from 
epoch in seconds - something that can be manipulated in a meaningful way?