I think you hit the periodic flush of IP route cache, which is fired
every 600 seconds per default.
(Check /proc/sys/net/ipv4/route/secret_interval )
For a 1GB machine, this hash table is so big that a full scan might take
more than 10 ms, even if empty.
Instead of using less RAM, you could just boot with rhash_entries=1024
to lower the size of this table.
Or just change secret_interval to 2000000 for example (not much more
because * HZ could overflow)
I just tried that and it seems to reduce the scan time. This is the
result for the first 40 minutes of runtime:
looping 1 milli seconds nanosleep ...
17:10:11/425384 #1 MAX 1996/83117/-268599896 us/tick/usec (at 2107848557)
17:10:11/427385 #2 MAX 2001/83327/2001 us/tick/usec (at 2107931884)
17:10:11/433534 #5 MAX 2149/89477/2150 us/tick/usec (at 2108187839)
17:27:02/5897 #505291 MAX 2512/104576/2513 us/tick/usec (at 1223589469)
The first ~10ms delay usually occurred after ~15 minutes. So one could
argue that the reported HIGH-value at 17:27:02 (GMT) is the first flush
of IP route cache. And all later flushes weren't longer than 2,5ms.
Thanks to all of you, especially Eric. Now it seems I got an instrument
to lower system response time.
PS: Unfortunately I had to remove some CC:-entries since the local
firewall seems to not allow anything but NNTP (for gmane) and HTTP.