netdev - Re: 0% cpu usasge after fresh boot or net restart but 10% CPU if kernel flush route cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 29 Jan 2010 10:06:37 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	cold cold <nedkonedev@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: 0% cpu usasge after fresh boot or net restart but 10% CPU if 
 kernel flush route cache

Le vendredi 29 janvier 2010 à 09:38 +0200, cold cold a écrit :

> I'm totally agree with you there must be some scheduler to release
> route cache over the time.
> So far i see garbage collector do this, but it cost a lot of CPU
> probably its is a bug or design problem don't know
> for this i make this 2 test to compare CPU usage with and without GC.
> 
> 
> / secret_interval 10 min,  1300000 route entries in cash ofter 10 min,
>  7k new route on empty cache 2k on 1300000  /
> all route cache parameters default. I try also with gc_elasticity from
> 8 to 2 and gc_interval from 60 to 1 but don't have
> too much difference.
> 
> What I'm trying to say is that flush cash is almost instant ( less
> then second on 1 CPU) so releasing of cash is not so heavy job
>  ( you are right can have a big impact on dropped frames because of
> cpu/ram congestion ) but my point is why GC need 5-6min
> 10% no  4 CPU to do same job ?
> --

Once again, 'flushing cache' is immediate, it only increments a global
variable (aka a generation number)

Then, later, when ip routing hits an entry with an old generation
number, this entry is discarded. This slows down processing, and your
router might drop packets during 5 to 60 seconds, while stale entries
are eliminated.

This delays the real cost of 'flush cache' in a smooth way, depending
on trafic you have.

Releasing 1.300.000 dst entries is expensive, no matter how you trigger
the release, because it has to go through RCU queueing, spinlocks,
kernel memory allocator logic, and touch a lot of memory.

In your previous "perf top" results, we saw most of kernel cpu cycles
were consumed outside of network stack, you might investigate why.

Using HPET time keeping is probably not very good for your machine...

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html