public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Andrew Morton <akpm@zip.com.au>
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: 13 Jul 2002 22:08:35 +0200	[thread overview]
Message-ID: <p73ofdbv1a4.fsf@oldwotan.suse.de> (raw)
In-Reply-To: Andrew Morton's message of "13 Jul 2002 04:45:16 +0200"

Andrew Morton <akpm@zip.com.au> writes:


> 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?

Comment from the x86-64 side: 

Current x86-64 NUMA essentially has no 'nodes', just each CPU has
local memory that is slightly faster than remote memory. This means
the node number would be always identical to the CPU number. As long
as the API provides it's ok for me. Just the node concept will not be
very useful on that platform. memblk will also be identity mapped to
node/cpu.

Some way to tell user space about memory affinity seems to be useful,
but...

General comment:

I don't see what the application should do with the memblk concept
currently. Just knowing about it doesn't seem too useful. 
Surely it needs some way to allocate memory in a specific memblk to be useful?
Also doesn't it need to know how much memory is available in each memblk?
(otherwise I don't see how it could do any useful partitioning)

-Andi


       reply	other threads:[~2002-07-13 20:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
2002-07-14 19:17     ` [patch[ Simple Topology API 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
2002-07-15 19:50 Jukka Honkela
  -- strict thread matches above, loose matches on Subject: below --
2002-07-13  0:35 Matthew Dobson
2002-07-13  2:49 ` Andrew Morton
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

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=p73ofdbv1a4.fsf@oldwotan.suse.de \
    --to=ak@suse.de \
    --cc=akpm@zip.com.au \
    --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