From: Eric Dumazet <dada1@cosmosbay.com>
To: Jarek Poplawski <jarkao2@o2.pl>
Cc: David Miller <davem@davemloft.net>,
ak@suse.de, netdev@vger.kernel.org, acme@redhat.com
Subject: Re: [PATCH] INET : removes per bucket rwlock in tcp/dccp ehash table
Date: Sun, 04 Nov 2007 22:23:10 +0100 [thread overview]
Message-ID: <472E383E.7080004@cosmosbay.com> (raw)
In-Reply-To: <472E0C24.9040009@o2.pl>
Jarek Poplawski a écrit :
> Jarek Poplawski wrote, On 11/04/2007 06:58 PM:
>
>> Eric Dumazet wrote, On 11/04/2007 12:31 PM:
>
> ...
>
>>> +static inline int inet_ehash_locks_alloc(struct inet_hashinfo *hashinfo)
>>> +{
>
> ...
>
>>> + if (sizeof(rwlock_t) != 0) {
>
> ...
>
>>> + for (i = 0; i < size; i++)
>>> + rwlock_init(&hashinfo->ehash_locks[i]);
>>
>> This looks better now, but still is doubtful to me: even if it's safe with
>> current rwlock implementation, can't we imagine some new debugging or
>> statistical code added, which would be called from rwlock_init() without
>> using rwlock_t structure? IMHO, if read_lock() etc. are called in such a
>> case, rwlock_init() should be done as well.
>
>
> Of course I mean: if sizeof(rwlock_t) == 0.
Given those two choices :
#if defined(CONFIG_SMP) || defined(CONFIG_PROVE__LOCKING)
kmalloc(sizeof(rwlock_t) * size);
#endif
and
if (sizeof(rwlock_t) != 0) {
kmalloc(sizeof(rwlock_t) * size);
}
I prefer the 2nd one. Less error prone, and no need to remember how are
spelled the gazillions CONFIG_something we have.
next prev parent reply other threads:[~2007-11-04 21:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-01 10:16 [PATCH] INET : removes per bucket rwlock in tcp/dccp ehash table Eric Dumazet
2007-11-01 11:03 ` David Miller
2007-11-01 11:20 ` Arnaldo Carvalho de Melo
2007-11-01 11:15 ` Ilpo Järvinen
2007-11-01 16:06 ` Jarek Poplawski
2007-11-01 18:00 ` Eric Dumazet
2007-11-01 16:14 ` Stephen Hemminger
2007-11-01 17:54 ` Eric Dumazet
2007-11-01 18:48 ` Rick Jones
2007-11-01 19:00 ` Eric Dumazet
2007-11-01 19:17 ` Eric Dumazet
2007-11-01 21:52 ` David Miller
2007-11-01 21:46 ` David Miller
2007-11-03 23:18 ` Andi Kleen
2007-11-03 23:23 ` David Miller
2007-11-04 0:54 ` Andi Kleen
2007-11-04 11:31 ` Eric Dumazet
2007-11-04 12:26 ` Andi Kleen
2007-11-04 13:05 ` Eric Dumazet
2007-11-04 21:56 ` David Miller
2007-11-04 23:01 ` Andi Kleen
2007-11-05 4:24 ` David Miller
2007-11-05 4:35 ` David Miller
2007-11-04 17:58 ` Jarek Poplawski
2007-11-04 18:15 ` Jarek Poplawski
2007-11-04 21:23 ` Eric Dumazet [this message]
2007-11-04 23:08 ` Jarek Poplawski
2007-11-07 10:41 ` David Miller
2007-11-07 12:13 ` Jarek Poplawski
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=472E383E.7080004@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=acme@redhat.com \
--cc=ak@suse.de \
--cc=davem@davemloft.net \
--cc=jarkao2@o2.pl \
--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.