From: Eric Dumazet <dada1@cosmosbay.com>
To: joonwpark81@gmail.com
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH] [IPV4] route: fix locking in rt_run_flush()
Date: Wed, 23 Jan 2008 21:44:25 +0100 [thread overview]
Message-ID: <4797A729.4030006@cosmosbay.com> (raw)
In-Reply-To: <20080123074320.GB9017@ehus.geninetworks.com>
joonwpark81@gmail.com a écrit :
> On Mon, Jan 21, 2008 at 02:40:43AM -0800, David Miller wrote:
>> From: Joonwoo Park <joonwpark81@gmail.com>
>> Date: Tue, 22 Jan 2008 00:08:57 +0900
>>
>>> The rt_run_flush() can be stucked if it was called while netdev is on the
>>> high load.
>>> It's possible when pushing rtable to rt_hash is faster than pulling
>>> from it.
>>>
>>> Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
>> I agree with the analysis of the problem, however not the solution.
>>
>> This will absolutely kill software interrupt latency.
>>
>> In fact, we have moved much of the flush work into a workqueue in
>> net-2.6.25 because of how important that is
>>
>> We need to find some other way to solve this.
>>
>
> Dave, Eric,
> Thanks so much for comments.
>
> I did stress tests and I found that the real problem was not consumer & supplier
> issue.
> It was the problem for me to innumerable enabling & disabling the softirq.
> But I'm still thinking need of considering issue 'faster caching than flush'. :)
>
> ifconfig up on heavy loaded interface.
> Before patching:
> time ifconfig eth1 up
> BUG: soft lockup - CPU#0 stuck for 11s! [events/0:9]
> ...
>
> After patching:
> time ifconfig eth1 up
> real 0m0.007s
> user 0m0.000s
> sys 0m0.004s
>
> Thanks!
> Joonwoo
>
>
>>From 87c29506de967e811ad5b57cd2e1a002134e878f Mon Sep 17 00:00:00 2001
> From: Joonwoo Park <joonwpark81@gmail.com>
> Date: Wed, 23 Jan 2008 15:16:54 +0900
> Subject: [PATCH] [IPV4] route: reduce locking/unlocking in rt_run_flush
>
> The rt_run_flush does spin_lock_bh/spin_unlock_bh for rt_hash_mask + 1
> times.
> The rt_hash_mask takes from 32767 to 65535, so it's big overhead.
> In addition, disable_bh/enable_bh for many times in the rt_run_flush
> can cause stuck on a machine with heavily pended softirqs.
>
> This patch reduces locking/unlocking as doing it with jumping the lock
> slots.
>
> ifconfig up on heavy loaded interface.
> Before:
> time ifconfig eth1 up
> BUG: soft lockup - CPU#0 stuck for 11s! [events/0:9]
> ...
>
> After:
> time ifconfig eth1 up
> real 0m0.007s
> user 0m0.000s
> sys 0m0.004s
>
Unfortunatly, your patch doesnt work on CONFIG_SMP=n (softirq will be disabled
for the whole scan of table)
Also, some machines around there have 2^22 slots in hash table, and NR_CPUS=4,
so softirqs will be disabled for a too long time.
Please try net-2.6.25 and submit patches on top of it if necessary, since
rt_run_flush() has pending changes, not in net-2.6
Note : The 'soft lockup' can be avoided by other means.
next prev parent reply other threads:[~2008-01-23 20:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-21 15:08 [PATCH] [IPV4] route: fix locking in rt_run_flush() Joonwoo Park
2008-01-21 10:40 ` David Miller
2008-01-21 21:14 ` Eric Dumazet
2008-01-23 7:43 ` joonwpark81
2008-01-23 20:44 ` Eric Dumazet [this message]
2008-01-24 5:06 ` Joonwoo Park
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=4797A729.4030006@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=joonwpark81@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 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.