From: Manfred Spraul <manfred@colorfullife.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [RFC,PATCH] use rcu for fasync_lock
Date: Sun, 21 Dec 2003 22:08:28 +0100 [thread overview]
Message-ID: <3FE60BCC.5090305@colorfullife.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0312211250370.13039@home.osdl.org>
Linus Torvalds wrote:
>On Sun, 21 Dec 2003, Manfred Spraul wrote:
>
>
>>Initially I tried to keep the patch as tiny as possible, thus I avoided
>>adding an inline function. But Stephen Hemminger convinced me to update
>>the network code, and thus it didn't matter and I've switched to an
>>inline function.
>>What do you think about the attached patch?
>>
>>
>
>Please, NO!
>
>Stuff like this
>
> - write_lock_irq(&fasync_lock);
> + if (s)
> + lock_sock(s);
> + else
> + spin_lock(&fasync_lock);
> +
>
>should not be allowed. That's especially true since the choice really is a
>static one depending on the caller.
>
>Just make the caller do the locking.
>
>
It's not that simple: the function does
kmalloc();
spin_lock();
use_allocation.
If the caller does the locking, then the kmalloc would have to use
GFP_ATOMIC, or the caller would have to do the alloc.
But: as far as I can see, these lines usually run under lock_kernel().
If this is true, then the spin_lock(&fasync_lock) won't cause any
scalability regression, and I'll use that lock instead of lock_sock,
even for network sockets.
--
Manfred
next prev parent reply other threads:[~2003-12-21 21:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-20 18:20 [RFC,PATCH] use rcu for fasync_lock Manfred Spraul
2003-12-20 21:10 ` [Lse-tech] " Stephen Hemminger
2003-12-20 21:35 ` Manfred Spraul
2003-12-21 11:36 ` Jamie Lokier
2003-12-21 12:40 ` Manfred Spraul
2003-12-21 14:14 ` Jamie Lokier
2003-12-21 14:59 ` Manfred Spraul
2003-12-21 15:08 ` Jamie Lokier
2004-01-02 21:15 ` Bill Davidsen
2004-01-02 22:41 ` Jamie Lokier
2004-01-03 1:09 ` Mike Fedyk
2004-01-03 21:28 ` Jamie Lokier
2004-01-04 19:01 ` Ingo Oeser
2004-01-04 19:20 ` Davide Libenzi
2004-01-05 21:17 ` Ingo Oeser
2004-01-05 22:24 ` Davide Libenzi
2003-12-21 15:14 ` Davide Libenzi
2003-12-21 15:17 ` Davide Libenzi
2003-12-21 15:28 ` Jamie Lokier
2003-12-21 18:38 ` OGAWA Hirofumi
2003-12-21 19:14 ` Manfred Spraul
2003-12-21 20:51 ` Linus Torvalds
2003-12-21 21:08 ` Manfred Spraul [this message]
2003-12-21 21:19 ` Linus Torvalds
2003-12-21 21:54 ` Manfred Spraul
2003-12-21 22:05 ` Linus Torvalds
2003-12-25 1:21 ` Manfred Spraul
2003-12-25 15:11 ` OGAWA Hirofumi
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=3FE60BCC.5090305@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=torvalds@osdl.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.