All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux kernel <linux-kernel@vger.kernel.org>,
	Mike Travis <travis@sgi.com>
Subject: Re: [PATCH] modules: Use a better scheme for refcounting
Date: Fri, 16 May 2008 10:09:11 +1000	[thread overview]
Message-ID: <200805161009.12142.rusty@rustcorp.com.au> (raw)
In-Reply-To: <482C9FC5.2070508@cosmosbay.com>

On Friday 16 May 2008 06:40:37 Eric Dumazet wrote:
> Current refcounting for modules (done if CONFIG_MODULE_UNLOAD=y)
> is using a lot of memory.

Hi Eric,

   I like this patch!  The plan was always to create a proper dynamic per-cpu
allocator which used the normal per-cpu offsets, but I think module refcounts
are worthwhile as a special case.

   Any chance I can ask you look at the issue of full dynamic per-cpu
allocation?  The problem of allocating memory which is laid out precisely
as the original per-cpu alloc is vexing on NUMA, and probably requires
reserving virtual address space and remapping into it, but the rewards
would be maximally-efficient per-cpu accessors, and getting rid of that
boutique allocator in module.c.

Only minor commentry on the patch itself:

> +#ifdef CONFIG_SMP
> +       char *refptr;
> +#else

void * would seem more natural here (love those gcc'isms)

> +#if defined(CONFIG_MODULE_UNLOAD) && defined(CONFIG_SMP)
> +       void *refptr = NULL;
> +#endif

Looks like you can skip this if you assign to mod->refptr directly below:

> +#if defined(CONFIG_MODULE_UNLOAD) && defined(CONFIG_SMP)
> +       refptr = percpu_modalloc(sizeof(local_t), sizeof(local_t), mod->name);
> +       if (!refptr)
> +               goto free_mod;
> +       mod->refptr = refptr;
> +#endif

And finally:

> +#if defined(CONFIG_MODULE_UNLOAD) && defined(CONFIG_SMP)
> +       if (refptr)
> +               percpu_modfree(refptr);
> +#endif

This if (refptr) seems redundant.

Thanks!
Rusty.

  parent reply	other threads:[~2008-05-16  0:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-15 20:40 [PATCH] modules: Use a better scheme for refcounting Eric Dumazet
2008-05-15 21:57 ` Andi Kleen
2008-05-16  4:44   ` Eric Dumazet
2008-05-16  0:09 ` Rusty Russell [this message]
2008-05-16  5:29   ` Eric Dumazet
2008-05-16 13:41     ` Mike Travis
2008-05-17  5:33       ` Rusty Russell
2008-05-17  7:36         ` Eric Dumazet
2008-05-18 14:31           ` Rusty Russell
2008-05-19 16:42             ` Christoph Lameter
2008-05-19 16:41           ` Christoph Lameter
2008-05-19 18:04             ` Mike Travis
2008-05-19 16:39         ` Christoph Lameter
  -- strict thread matches above, loose matches on Subject: below --
2009-02-03  3:01 Rusty Russell

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=200805161009.12142.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=travis@sgi.com \
    /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.