netdev - Re: Strange CPU load when flushing route cache (kernel 2.6.31.6)

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Nov 2009 14:48:05 +0100 (CET)
From:	Jesper Dangaard Brouer <hawk@...u.dk>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Jesper Dangaard Brouer <hawk@...x.dk>,
	Linux Kernel Network Hackers <netdev@...r.kernel.org>,
	Robert Olsson <robert@...julf.net>
Subject: Re: Strange CPU load when flushing route cache (kernel 2.6.31.6)

On Mon, 23 Nov 2009, Eric Dumazet wrote:

> Jesper Dangaard Brouer a écrit :
>> On Mon, 2009-11-23 at 11:29 +0100, Eric Dumazet wrote:
>
>>> Sure, after a flush, we have to rebuild the cache, so extra work is expected.
>>
>> But the old 2.6.25.7 do NOT show this behavior... That is the real
>> issue...
>
> Previous kernels were crashing, because flush was immediate and not deferred
> as today.
>
> During flush, we were dropping enormous amounts of packets.

Ahh... Now I remember that was why I was flushing the cache so often.  If 
I flushed the route cache before it got too big then it was not a 
problem with packet drops occuring.


> Now, its possible to have setups with equilibrium and no packet loss,
> because we smoothtly invalidate cache entries.

Which is a good thing :-)


>> I did the cache flushing due to some historical issues, that I think you
>> did a fix for... Guess I can drop the flushing and see if the garbage
>> collection can keep up...
>
> Yes it can. Unless your route cache settings are not optimal.

I'll adjust my flushing interval, or disable it and monitor it.


>>> Do you run a 2G/2G User/Kernel split kernel ?
>>
>> Not sure, how do I check?
>
> grep LowTotal /proc/meminfo

Yes, guess I'm using User/Kernel split.

grep LowTotal /proc/meminfo
LowTotal:         747080 kB

What does that mean?  Is it bad? What should I run on a 32-bit 
system/kernel?


Can you recommend any other /proc/sys/ tuning options?

Does my kernel boot option rhash_entries=262143 make sense anymore?
Or do we adjust the hash bucket size dynamically these days?

Cheers,
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------