From: Eric Dumazet <dada1@cosmosbay.com>
To: Hans de Goede <j.w.r.degoede@hhs.nl>
Cc: Dave Jones <davej@redhat.com>, netdev@vger.kernel.org
Subject: Re: cat /proc/net/tcp takes 0.5 seconds on x86_64
Date: Tue, 26 Aug 2008 23:27:31 +0200 [thread overview]
Message-ID: <48B47543.8080701@cosmosbay.com> (raw)
In-Reply-To: <48B46E89.4030104@hhs.nl>
Hans de Goede a écrit :
> Eric Dumazet wrote:
>> Hans de Goede a écrit :
>>> Eric Dumazet wrote:
>>>> Dave Jones a écrit :
>>>>> Just had this bug reported against our development tree..
>>> <snip>
>>>>> > [hans@localhost devel]$ time cat /proc/net/tcp
>>>>> > <snip>
>>>>> > real 0m0.520s
>>>>> > user 0m0.000s
>>>>> > sys 0m0.446s
>>>>> > > Thats amazingly slow, esp as I only have 8 tcp connections open.
>>>>> > > Some maybe usefull info: top reports a very high load (50%)
>>>>> from soft IRQ's.
>>>>> > > Anyways changing this to a kernel bug.
>>>>>
>>>>
>>>> I wonder why this qualifies as a "kernel bug". This is a well known
>>>> problem.
>>>>
>>>
>>> No its not, /proc/net/tcp may be slow in general but not *this* slow ...
>>>
>>> <snip>
>>>
>>>>
>>>> Time difference between /proc/net/tcp and netlink on a 4GB x86_64
>>>> machine :
>>>>
>>>> # dmesg | grep "TCP established hash"
>>>> TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
>>>> # time cat /proc/net/tcp >/dev/null
>>>>
>>>> real 0m0.091s
>>>> user 0m0.001s
>>>> sys 0m0.090s
>>>
>>> As quoted above my idle x86_64, using the exact same hash table size,
>>> running 2.6.27-rc2.git1 uses 0.520 seconds for that same command,
>>> thats a difference of more then a factor 50 !!
>>>
>>> This is not about /proc/net/tcp not being fast, this is about it
>>> haven gotten slower by a factor of 50!
>>>
>>> Also notice that this slowdown does not happen on i386.
>>
>> And your .config files on i386 and x86_64 are ?
>> Some configuration options can slow down all lock/unlock operations
>> (CONFIG_SMP, CONFIG_PREEMPT, CONFIG_PROVE_LOCKING,
>> CONFIG_DEBUG_SPINLOCK, CONFIG_NR_CPUS ...)
>>
>
> Attached
>
>> If you TCP hash table has 512.000 slots (I am just guessing, you didnt
>> provide this information), it can make a huge difference.
>
> I did provide that information: "using the exact same hash table size"
> and then quoting your first mail in this thread:
> "TCP established hash table entries: 262144 (order: 10, 4194304 bytes)"
>
>>>
>>> Anyways I'll try 2.6.27-rc4 and report back with its results.
>>>
>>
>> Yes, please, but nothing really changed in this area in the recent
>> times...
>>
>
> I'm afraid that atleast the Fedora rc4 build won't boot on my machine ...
>
>> We added some checks so that softirqs can preempt us.
>> Latencies used to be very high, and are now bonded, at the price of
>> potential slowdown for the /proc/net/tcp reader.
>
> Slowdown as in 2x or 4x as slow I presume, not 50x ?
I dont know, you tell us 50x, but nowhere I saw your numbers on i386,
nor the amount of memory of your test machine.
One important thing to remember is that on i386, LOWMEM is less than 1GB,
so a 4GB server will give different hash sizes depending on being 32 or 64 bits.
With a 32 bits kernel:
# dmesg | grep "TCP established"
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
# time cat /proc/net/tcp >/dev/null
real 0m0.025s
user 0m0.000s
sys 0m0.017s
While on a 64 bits kernel :
# dmesg | grep "TCP established hash"
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
# time cat /proc/net/tcp >/dev/null
real 0m0.091s
user 0m0.001s
sys 0m0.090s
So I see a 3x on my machine, not a 50x as you ?
next prev parent reply other threads:[~2008-08-26 21:31 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-459782-176318@bugzilla.redhat.com>
[not found] ` <200808261549.m7QFnVUN032543@bz-web1.app.phx.redhat.com>
2008-08-26 16:37 ` cat /proc/net/tcp takes 0.5 seconds on x86_64 Dave Jones
2008-08-26 18:32 ` Eric Dumazet
2008-08-26 19:01 ` Hans de Goede
2008-08-26 20:39 ` Eric Dumazet
2008-08-26 20:58 ` Hans de Goede
2008-08-26 21:27 ` Eric Dumazet [this message]
2008-08-27 9:14 ` Hans de Goede
2008-08-27 9:05 ` David Miller
2008-08-27 9:45 ` Hans de Goede
2008-08-27 9:39 ` David Miller
2008-08-27 4:19 ` Herbert Xu
2008-08-27 9:07 ` Hans de Goede
2008-08-27 12:41 ` Andi Kleen
2008-08-27 21:29 ` Trent Piepho
2008-08-27 21:47 ` Andi Kleen
2008-08-27 22:54 ` Andi Kleen
2008-08-27 21:29 ` David Miller
2008-08-27 21:48 ` Stephen Hemminger
2008-08-27 22:09 ` David Miller
2008-08-28 6:20 ` Eric Dumazet
2008-08-28 6:51 ` David Miller
2008-08-28 7:13 ` Eric Dumazet
2008-08-28 7:57 ` David Miller
2008-08-28 9:52 ` Eric Dumazet
2008-08-28 7:26 ` Andi Kleen
2008-08-27 22:34 ` Andi Kleen
2008-08-27 22:39 ` David Miller
2008-08-27 22:57 ` Andi Kleen
2008-08-27 23:07 ` David Miller
2008-08-27 23:09 ` Eric Dumazet
2008-08-27 23:15 ` David Miller
2008-08-27 23:35 ` Andi Kleen
2008-08-27 23:43 ` Eric Dumazet
2008-08-27 23:45 ` David Miller
2008-08-28 0:40 ` Eric Dumazet
2008-08-28 7:45 ` Andi Kleen
2008-08-28 7:59 ` David Miller
2008-08-28 8:12 ` Hans de Goede
2008-08-28 8:04 ` David Miller
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=48B47543.8080701@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=davej@redhat.com \
--cc=j.w.r.degoede@hhs.nl \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.