From: Tejun Heo <tj@kernel.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org,
hpa@zytor.com, jeremy@goop.org, cpw@sgi.com, mingo@elte.hu,
tony.luck@intel.com, Nick Piggin <npiggin@suse.de>
Subject: Re: [PATCH 09/10] percpu: implement new dynamic percpu allocator
Date: Fri, 20 Feb 2009 12:02:37 +0900 [thread overview]
Message-ID: <499E1D4D.20609@kernel.org> (raw)
In-Reply-To: <499E1D01.2040408@kernel.org>
Oops, forgot to cc Nick. cc'ing and quoting whole body.
Tejun Heo wrote:
> Hello, Rusty.
>
> Rusty Russell wrote:
>> On Wednesday 18 February 2009 22:34:35 Tejun Heo wrote:
>>> Impact: new scalable dynamic percpu allocator which allows dynamic
>>> percpu areas to be accessed the same way as static ones
>>>
>>> Implement scalable dynamic percpu allocator which can be used for both
>>> static and dynamic percpu areas. This will allow static and dynamic
>>> areas to share faster direct access methods. This feature is optional
>>> and enabled only when CONFIG_HAVE_DYNAMIC_PER_CPU_AREA is defined by
>>> arch. Please read comment on top of mm/percpu.c for details.
>> Hi Tejun,
>>
>> One question. Are you thinking that to be defined by every SMP arch
>> long-term?
>
> Yeap, definitely.
>
>> Because there are benefits in having &<percpuvar> == valid
>> percpuptr, such as passing them around as parameters. If so, IA64
>> will want a dedicated per-cpu area for statics (tho it can probably
>> just map it somehow, but it has to be 64k).
>
> Hmmm... Don't have much idea about ia64 and its magic 64k. Can it
> somehow be used for the first chunk?
>
>> It'd also be nice to use your generalised module_percpu allocator for the
>> !CONFIG_HAVE_DYNAMIC_PER_CPU_AREA case, but doesn't really matter if that's
>> temporary anyway.
>
> Yeap, once the conversion is complete, the old allocator will go away
> so there's no reason to put more work into it.
>
>>> +#define PCPU_UNIT_PAGES_SHIFT ((int)__pcpu_unit_pages_shift)
>>> +#define PCPU_UNIT_PAGES ((int)__pcpu_unit_pages)
>>> +#define PCPU_UNIT_SHIFT ((int)__pcpu_unit_shift)
>>> +#define PCPU_UNIT_SIZE ((int)__pcpu_unit_size)
>>> +#define PCPU_CHUNK_SIZE ((int)__pcpu_chunk_size)
>>> +#define PCPU_NR_SLOTS ((int)__pcpu_nr_slots)
>> These pseudo-constants seem like a really weird thing to do to me.
>
> I explained this in the reply to Andrew's comment. It's
> non-really-constant-but-should-be-considered-so-by-users thing. Is it
> too weird? Even if I add comment explaning it?
>
>> And AFAICT you have the requirement that PCPU_UNIT_PAGES*PAGE_SIZE >=
>> sizeof(.data.percpu). Should probably note that somewhere.
>
> __pcu_unit_pages_shift is adjusted automatically according to
> sizeof(.data.percpu), so it will adapt as necessary. After the
> initial adjustment, it should be considered constant, so the above
> seemingly weird hack.
>
>>> +static DEFINE_MUTEX(pcpu_mutex); /* one mutex to rule them all */
>>> +static struct list_head *pcpu_slot; /* chunk list slots */
>>> +static struct rb_root pcpu_addr_root = RB_ROOT; /* chunks by address */
>> rbtree might be overkill on first cut. I'm bearing in mind that Christoph L
>> had a nice patch to use dynamic percpu allocation in the sl*b allocators;
>> which would mean this needs to only use get_free_page.
>
> Hmmm... the reverse mapping can be piggy backed on vmalloc by adding a
> private pointer to the vm_struct but rbtree isn't too difficult to use
> so I just did it directly. Nick, what do you think about adding
> private field to vm_struct and providing a reverse map function?
>
> As for the sl*b allocation thing, can you please explain in more
> detail or point me to the patches / threads?
>
> Thanks. :-)
>
--
tejun
next prev parent reply other threads:[~2009-02-20 3:03 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-18 12:04 [PATCHSET x86/core/percpu] implement dynamic percpu allocator Tejun Heo
2009-02-18 12:04 ` [PATCH 01/10] vmalloc: call flush_cache_vunmap() from unmap_kernel_range() Tejun Heo
2009-02-19 12:06 ` Nick Piggin
2009-02-19 22:36 ` David Miller
2009-02-18 12:04 ` [PATCH 02/10] module: fix out-of-range memory access Tejun Heo
2009-02-19 12:08 ` Nick Piggin
2009-02-20 7:16 ` Tejun Heo
2009-02-18 12:04 ` [PATCH 03/10] module: reorder module pcpu related functions Tejun Heo
2009-02-18 12:04 ` [PATCH 04/10] alloc_percpu: change percpu_ptr to per_cpu_ptr Tejun Heo
2009-02-18 12:04 ` [PATCH 05/10] alloc_percpu: add align argument to __alloc_percpu Tejun Heo
2009-02-18 12:04 ` [PATCH 06/10] percpu: kill percpu_alloc() and friends Tejun Heo
2009-02-19 0:17 ` Rusty Russell
2009-03-11 18:36 ` Tony Luck
2009-03-11 22:44 ` Rusty Russell
2009-03-12 2:06 ` Tejun Heo
2009-02-18 12:04 ` [PATCH 07/10] vmalloc: implement vm_area_register_early() Tejun Heo
2009-02-19 0:55 ` Tejun Heo
2009-02-19 12:09 ` Nick Piggin
2009-02-18 12:04 ` [PATCH 08/10] vmalloc: add un/map_kernel_range_noflush() Tejun Heo
2009-02-19 12:17 ` Nick Piggin
2009-02-20 1:27 ` Tejun Heo
2009-02-20 7:15 ` Subject: [PATCH 08/10 UPDATED] " Tejun Heo
2009-02-20 8:32 ` Andrew Morton
2009-02-21 3:21 ` Tejun Heo
2009-02-18 12:04 ` [PATCH 09/10] percpu: implement new dynamic percpu allocator Tejun Heo
2009-02-19 10:10 ` Andrew Morton
2009-02-19 11:01 ` Ingo Molnar
2009-02-20 2:45 ` Tejun Heo
2009-02-19 12:07 ` Rusty Russell
2009-02-20 2:35 ` Tejun Heo
2009-02-20 3:04 ` Andrew Morton
2009-02-20 5:29 ` Tejun Heo
2009-02-24 2:52 ` Rusty Russell
2009-02-19 11:51 ` Rusty Russell
2009-02-20 3:01 ` Tejun Heo
2009-02-20 3:02 ` Tejun Heo [this message]
2009-02-24 2:56 ` Rusty Russell
2009-02-24 5:27 ` [PATCH tj-percpu] percpu: add __read_mostly to variables which are mostly read only Tejun Heo
2009-02-24 5:47 ` [PATCH 09/10] percpu: implement new dynamic percpu allocator Tejun Heo
2009-02-24 17:41 ` Luck, Tony
2009-02-26 3:17 ` Tejun Heo
2009-02-27 19:41 ` Luck, Tony
2009-02-19 12:36 ` Nick Piggin
2009-02-20 3:04 ` Tejun Heo
2009-02-20 7:30 ` [PATCH UPDATED " Tejun Heo
2009-02-20 8:37 ` Andrew Morton
2009-02-21 3:23 ` Tejun Heo
2009-02-21 3:42 ` [PATCH tj-percpu] percpu: s/size/bytes/g in new percpu allocator and interface Tejun Heo
2009-02-21 7:48 ` Tejun Heo
2009-02-21 7:55 ` [PATCH tj-percpu] percpu: clean up size usage Tejun Heo
2009-02-21 7:56 ` Tejun Heo
2009-02-18 12:04 ` [PATCH 10/10] x86: convert to the new dynamic percpu allocator Tejun Heo
2009-02-18 13:43 ` [PATCHSET x86/core/percpu] implement " Ingo Molnar
2009-02-19 0:31 ` Tejun Heo
2009-02-19 10:51 ` Rusty Russell
2009-02-19 11:06 ` Ingo Molnar
2009-02-19 12:14 ` Rusty Russell
2009-02-20 3:08 ` Tejun Heo
2009-02-20 5:36 ` Tejun Heo
2009-02-20 7:33 ` Tejun Heo
2009-02-19 0:30 ` Tejun Heo
2009-02-19 11:07 ` Ingo Molnar
2009-02-20 3:17 ` Tejun Heo
2009-02-20 9:32 ` Ingo Molnar
2009-02-21 7:10 ` Tejun Heo
2009-02-21 7:33 ` Tejun Heo
2009-02-22 19:38 ` Ingo Molnar
2009-02-23 0:43 ` Tejun Heo
2009-02-23 10:17 ` Ingo Molnar
2009-02-23 13:38 ` [patch] x86: optimize __pa() to be linear again on 64-bit x86 Ingo Molnar
2009-02-23 14:08 ` Nick Piggin
2009-02-23 14:53 ` Ingo Molnar
2009-02-24 16:00 ` Andi Kleen
2009-02-27 5:57 ` Tejun Heo
2009-02-27 6:57 ` Ingo Molnar
2009-02-27 7:11 ` Tejun Heo
2009-02-22 19:27 ` [PATCHSET x86/core/percpu] implement dynamic percpu allocator Ingo Molnar
2009-02-23 0:47 ` Tejun Heo
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=499E1D4D.20609@kernel.org \
--to=tj@kernel.org \
--cc=cpw@sgi.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@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 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).