From: Richard Kennedy <richard@rsk.demon.co.uk>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Kyle McMartin <kyle@infradead.org>, Takashi Iwai <tiwai@suse.de>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] module: kzalloc mod->ref
Date: Sun, 25 Jan 2009 15:52:51 +0000 [thread overview]
Message-ID: <1232898771.3658.18.camel@localhost.localdomain> (raw)
In-Reply-To: <200901151303.20006.rusty@rustcorp.com.au>
On Thu, 2009-01-15 at 13:03 +1030, Rusty Russell wrote:
>
>
> On Thursday 15 January 2009 04:47:48 Kyle McMartin wrote:
>
> > On Wed, Jan 14, 2009 at 05:51:27PM +0000, richard kennedy wrote:
>
> > > Aside from the code in socket does this reference count really get
> used
>
> > > that often? Atomic_t gets used for ref counts is lots of other
> places in
>
> > > the kernel, so why not turn module_ref into an atomic counter &
> drop the
>
> > > array entirely saving all of the memory & disk space?
>
> The code was originally written with the intent that networking would
> inc and dec a module count on every *packet*. It doesn't, however
> (though it would be interesting to instrument who does manip it, and
> how often).
>
> I suspect that we could get away with an atomic_t and noone would
> notice, but I'd like to see evidence one way or the other.
>
> Cheers,
>
> Rusty.
Hi Rusty,
I've been running module reference counts as atomic_t on my desktop
(x86_64 AMD X2) all week and haven't been able to measure any
significant performance differences. I guess more cpus & server
workloads could show up something, but I don't have access to that sort
of hardware.
The one issue I am seeing is with my simple test harness, which is just
a very basic socket client/server. With the existing ref counting code,
when running several copies of the client I sometimes get EADDRNOTAVAIL
(-99) errors on socket connect(). But I don't see any errors with the
atomic_t ref counting.
I'm still trying to debug this, but I haven't yet found where in the
network stack these errors are coming from.
regards
Richard
next prev parent reply other threads:[~2009-01-25 15:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-14 3:35 [PATCH] module: kzalloc mod->ref Kyle McMartin
2009-01-14 5:54 ` [PATCHv2] " Kyle McMartin
2009-01-14 9:09 ` [PATCH] " Takashi Iwai
2009-01-14 15:58 ` Kyle McMartin
2009-01-14 16:25 ` Takashi Iwai
2009-01-14 19:29 ` Valdis.Kletnieks
2009-01-14 20:37 ` Takashi Iwai
2009-01-14 20:53 ` Kyle McMartin
2009-01-14 17:51 ` richard kennedy
2009-01-14 18:17 ` Kyle McMartin
[not found] ` <200901151303.20006.rusty@rustcorp.com.au>
2009-01-25 15:52 ` Richard Kennedy [this message]
[not found] ` <200901151521.47326.rusty@rustcorp.com.au>
2009-01-15 6:03 ` Kyle McMartin
[not found] ` <200901261751.21817.rusty@rustcorp.com.au>
2009-01-27 1:36 ` Rusty Russell
2009-01-27 1:58 ` Tejun Heo
2009-01-27 13:15 ` Ingo Molnar
2009-01-28 12:24 ` Rusty Russell
2009-01-14 10:15 ` richard kennedy
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=1232898771.3658.18.camel@localhost.localdomain \
--to=richard@rsk.demon.co.uk \
--cc=kyle@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=tiwai@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox