public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: cold cold <nedkonedev@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: 0% cpu usasge after fresh boot or net restart but 10% CPU if kernel flush route cache
Date: Fri, 29 Jan 2010 10:06:37 +0100	[thread overview]
Message-ID: <1264755997.3184.8.camel@edumazet-laptop> (raw)
In-Reply-To: <41ac0f9e1001282338n76217590u61877f181c05dc06@mail.gmail.com>

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...



      reply	other threads:[~2010-01-29  9:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-26 16:58 0% cpu usasge after fresh boot or net restart but 10% CPU if kernel flush route cache cold cold
2010-01-27 15:26 ` Eric Dumazet
2010-01-27 19:53   ` cold cold
2010-01-27 21:18     ` Eric Dumazet
2010-01-28  9:14       ` cold cold
2010-01-28 16:09         ` Eric Dumazet
2010-01-28 16:26           ` cold cold
2010-01-28 17:06             ` Eric Dumazet
2010-01-28 18:49               ` cold cold
2010-01-28 21:16                 ` Eric Dumazet
2010-01-29  7:38                   ` cold cold
2010-01-29  9:06                     ` Eric Dumazet [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1264755997.3184.8.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=nedkonedev@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox