From: Andrew Morton <akpm@zip.com.au>
To: colpatch@us.ibm.com
Cc: linux-kernel@vger.kernel.org,
Michael Hohnbaum <hohnbaum@us.ibm.com>,
Martin Bligh <mjbligh@us.ibm.com>,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [patch[ Simple Topology API
Date: Fri, 12 Jul 2002 19:49:05 -0700 [thread overview]
Message-ID: <3D2F9521.96D7080B@zip.com.au> (raw)
In-Reply-To: 3D2F75D7.3060105@us.ibm.com
Matthew Dobson wrote:
>
> Here is a very rudimentary topology API for NUMA systems. It uses prctl() for
> the userland calls, and exposes some useful things to userland. It would be
> nice to expose these simple structures to both users and the kernel itself.
> Any architecture wishing to use this API simply has to write a .h file that
> defines the 5 calls defined in core_ibmnumaq.h and include it in asm/mmzone.h.
Matt,
I suspect what happens when these patches come out is that most people simply
don't have the knowledge/time/experience/context to judge them, and nothing
ends up happening. No way would I pretend to be able to comment on the
big picture, that's for sure.
If the code is clean, the interfaces make sense, the impact on other
platforms is minimised and the stakeholders are OK with it then that
should be sufficient, yes?
AFAIK, the interested parties with this and the memory binding API are
ia32-NUMA, ia64, PPC, some MIPS and x86-64-soon. It would be helpful
if the owners of those platforms could review this work and say "yes,
this is something we can use and build upon". Have they done that?
I'd have a few micro-observations:
> ...
> --- linux-2.5.25-vanilla/kernel/membind.c Wed Dec 31 16:00:00 1969
> +++ linux-2.5.25-api/kernel/membind.c Fri Jul 12 16:13:17 2002
> ..
> +inline int memblk_to_node(int memblk)
The inlines with global scope in this file seem strange?
Matthew Dobson wrote:
>
> Here is a Memory Binding API
> ...
> + memblk_binding: { MEMBLK_NO_BINDING, MPOL_STRICT }, \
> ...
> +typedef struct memblk_list {
> + memblk_bitmask_t bitmask;
> + int behavior;
> + rwlock_t lock;
> +} memblk_list_t;
Is is possible to reduce this type to something smaller for
CONFIG_NUMA=n?
In the above task_struct initialiser you should initialise the
rwlock to RWLOCK_LOCK_UNLOCKED.
It's nice to use the `name:value' initialiser format in there, too.
> ...
> +int set_memblk_binding(memblk_bitmask_t memblks, int behavior)
> +{
> ...
> + read_lock_irqsave(¤t->memblk_binding.lock, flags);
Your code accesses `current' a lot. You'll find that the code
generation is fairly poor - evaluating `current' chews 10-15
bytes of code. You can perform a manual CSE by copying current
into a local, and save a few cycles.
> ...
> +struct page * _alloc_pages(unsigned int gfp_mask, unsigned int order)
> +{
> ...
> + spin_lock_irqsave(&node_lock, flags);
> + temp = pgdat_list;
> + spin_unlock_irqrestore(&node_lock, flags);
Not sure what you're trying to lock here, but you're not locking
it ;) This is either racy code or unneeded locking.
Thanks.
next prev parent reply other threads:[~2002-07-13 2:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-13 0:35 [patch[ Simple Topology API Matthew Dobson
2002-07-13 2:49 ` Andrew Morton [this message]
2002-07-15 18:49 ` Matthew Dobson
2002-07-13 8:04 ` Alexander Viro
2002-07-13 17:13 ` Albert D. Cahalan
2002-07-15 23:52 ` Matthew Dobson
[not found] <3D2F75D7.3060105@us.ibm.com.suse.lists.linux.kernel>
[not found] ` <3D2F9521.96D7080B@zip.com.au.suse.lists.linux.kernel>
2002-07-13 20:08 ` Andi Kleen
2002-07-14 19:17 ` Linus Torvalds
2002-07-14 19:43 ` Andi Kleen
2002-07-15 2:34 ` Eric W. Biederman
2002-07-15 15:25 ` Sandy Harris
2002-07-15 16:33 ` Chris Friesen
2002-07-16 10:30 ` Eric W. Biederman
2002-07-16 12:59 ` Rik van Riel
2002-07-16 15:45 ` Martin J. Bligh
2002-07-16 19:03 ` Martin J. Bligh
2002-07-16 22:29 ` Matthew Dobson
2002-07-17 0:21 ` Michael Hohnbaum
2002-07-15 17:48 ` Matthew Dobson
-- strict thread matches above, loose matches on Subject: below --
2002-07-15 19:50 Jukka Honkela
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=3D2F9521.96D7080B@zip.com.au \
--to=akpm@zip.com.au \
--cc=colpatch@us.ibm.com \
--cc=hohnbaum@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjbligh@us.ibm.com \
--cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox