From: Andrew Morton <akpm@digeo.com>
To: Ravikiran G Thirumalai <kiran@in.ibm.com>
Cc: linux-kernel@vger.kernel.org,
Rusty Russell <rusty@rustcorp.com.au>,
dipankar@in.ibm.com
Subject: Re: [patch] kmalloc_percpu -- 2 of 2
Date: Wed, 04 Dec 2002 11:34:35 -0800 [thread overview]
Message-ID: <3DEE58CB.737259DB@digeo.com> (raw)
In-Reply-To: 20021204174550.B17375@in.ibm.com
Ravikiran G Thirumalai wrote:
>
> Here's a 2.5.50 version of kmalloc_percpu originally submitted by Dipankar.
> +/* Use these with kmalloc_percpu */
> +#define get_cpu_ptr(ptr) per_cpu_ptr(ptr, get_cpu())
> +#define put_cpu_ptr(ptr) put_cpu()
These names sound very much like get_cpu_var() and put_cpu_var(),
yet they are using a quite different subsystem. It would be good
to choose something more distinct. Not that I can think of anything
at present ;)
The commentary above these functions should clearly state that thou
shalt not sleep between them.
> ...
> --- linux-2.5.50/kernel/Makefile Thu Nov 28 04:05:51 2002
> +++ kmalloc_percpu-2.5.50/kernel/Makefile Sun Dec 1 11:54:49 2002
> @@ -4,7 +4,7 @@
>
> export-objs = signal.o sys.o kmod.o workqueue.o ksyms.o pm.o exec_domain.o \
> printk.o platform.o suspend.o dma.o module.o cpufreq.o \
> - profile.o rcupdate.o intermodule.o
> + profile.o rcupdate.o intermodule.o percpu.o
I suppose so. It _could_ be in mm/percpu.c
> ...
> +static int data_blklist_count =
> + sizeof (data_blklist) / sizeof (struct percpu_data_blklist);
The ARRAY_SIZE macro is suitable here.
> +static struct percpu_data_blk *
> +percpu_data_blk_alloc(struct percpu_data_blklist *blklist, int flags)
> ...
> +static void
> +percpu_data_blk_free(struct percpu_data_blk *blkp)
> ...
> +static int
> +percpu_data_mem_grow(struct percpu_data_blklist *blklist, int flags)
> ...
> +static void __init
> +percpu_data_blklist_init(struct percpu_data_blklist *blklist)
> ...
> +static struct percpu_data_blklist *
> +percpu_data_get_blklist(size_t size, int flags)
> ...
> +static int
> +__percpu_interlaced_alloc_one(struct percpu_data_blklist *blklist,
> + struct percpu_data_blk *blkp)
> ...
> +static int
> +__percpu_interlaced_alloc(struct percpu_data *percpu,
> + struct percpu_data_blklist *blklist, int flags)
> ...
> +static int
> +percpu_interlaced_alloc(struct percpu_data *pdata, size_t size, int flags)
> ...
> +static void
> +percpu_data_blk_destroy(struct percpu_data_blklist *blklist,
> + struct percpu_data_blk *blkp)
> ...
> +static void
> +__percpu_interlaced_free(struct percpu_data_blklist *blklist,
> + struct percpu_data *percpu)
> ...
> +static void
> +percpu_interlaced_free(struct percpu_data *percpu)
> ...
ummm. What on earth is all that stuff?
> +void *
> +kmalloc_percpu(size_t size, int flags)
> +{
> + int i;
> + struct percpu_data *pdata = kmalloc(sizeof (*pdata), flags);
> +
> + if (!pdata)
> + goto out_done;
> + pdata->blkp = NULL;
> + if (size <= (malloc_sizes[0].cs_size >> 1)) {
> + if (!percpu_interlaced_alloc(pdata, size, flags))
> + goto out;
> + } else {
> + for (i = 0; i < NR_CPUS; i++) {
> + if (!cpu_possible(i))
> + continue;
> + pdata->ptrs[i] = kmalloc(size, flags);
> + if (!pdata->ptrs[i])
> + goto unwind_oom;
> + }
> + }
> + /* Catch derefs w/o wrappers */
> + return (void *) (~(unsigned long) pdata);
> +
> +unwind_oom:
> + while (--i >= 0) {
> + if (!cpu_possible(i))
> + continue;
> + kfree(pdata->ptrs[i]);
> + }
> +out:
> + kfree(pdata);
> +out_done:
> + return NULL;
> +}
If we were to remove the percpu_interlaced_alloc() leg here, we'd
have a nice, simple per-cpu kmalloc implementation.
Could you please explain what all the other code is there for?
next prev parent reply other threads:[~2002-12-04 19:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-04 12:12 [patch] kmalloc_percpu -- 1 of 2 Ravikiran G Thirumalai
2002-12-04 12:15 ` [patch] kmalloc_percpu -- 2 " Ravikiran G Thirumalai
2002-12-04 19:34 ` Andrew Morton [this message]
2002-12-05 3:42 ` Dipankar Sarma
2002-12-05 4:32 ` Andrew Morton
2002-12-05 4:47 ` William Lee Irwin III
2002-12-05 10:53 ` Dipankar Sarma
2002-12-05 11:23 ` yodaiken
2002-12-05 11:28 ` William Lee Irwin III
2002-12-05 12:41 ` Dipankar Sarma
2002-12-05 15:08 ` yodaiken
2002-12-05 20:02 ` Andrew Morton
2002-12-05 21:23 ` Dipankar Sarma
2002-12-05 22:15 ` Andrew Morton
2002-12-09 5:30 ` Ravikiran G Thirumalai
2002-12-09 5:57 ` Andrew Morton
2002-12-09 19:28 ` Andrew Morton
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=3DEE58CB.737259DB@digeo.com \
--to=akpm@digeo.com \
--cc=dipankar@in.ibm.com \
--cc=kiran@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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;
as well as URLs for NNTP newsgroup(s).