From: Andi Kleen <andi@firstfloor.org>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: David Rientjes <rientjes@google.com>,
Chris Worley <worleys@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: Off topic: Numactl "distance" wrong
Date: Fri, 03 Apr 2009 23:55:09 +0200 [thread overview]
Message-ID: <87r609jtc2.fsf@basil.nowhere.org> (raw)
In-Reply-To: <86802c440904031448yc6d499ckd9cb969ce136f477@mail.gmail.com> (Yinghai Lu's message of "Fri, 3 Apr 2009 14:48:31 -0700")
Yinghai Lu <yhlu.kernel@gmail.com> writes:
> On Fri, Apr 3, 2009 at 2:43 PM, David Rientjes <rientjes@google.com> wrote:
>>
>> Yinghai, can you elaborate on exactly what type of interface you can
>> imagine for modifying the distance for nodes through sysfs? It seems like
>> you'd have to report the entire physical topology in one write, for which
>> we currently don't have an interface for beyond pxms, instead of per-node
>> distances to remote nodes.
>
> acpi_numa_slit_init() in srat_64.c will have one copy (called
> acpi_slit) of SLIT, if there is SLIT from ACPI.
>
> so if numa is enabled, could expose that acpi_slit via sysfs for the
> user to update it.
That's not enough. You would need to redo all the zone fallback tables
in the VM that are initialized based on topology, do new scheduler
topologies and all kind of other stuff.
Besides I don't know any user space software which actually does anything
with the distances. The kernel does, but for it it doesn't make much difference
on smaller systems.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2009-04-03 21:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-03 20:02 Off topic: Numactl "distance" wrong Chris Worley
2009-04-03 20:16 ` Brice Goglin
2009-04-03 20:49 ` Yinghai Lu
2009-04-03 21:01 ` Cliff Wickman
2009-04-03 21:43 ` Yinghai Lu
2009-04-03 21:24 ` Andi Kleen
2009-04-03 21:43 ` David Rientjes
2009-04-03 21:48 ` Yinghai Lu
2009-04-03 21:52 ` David Rientjes
2009-04-03 21:55 ` Andi Kleen [this message]
2009-04-03 22:15 ` Yinghai Lu
2009-04-07 2:52 ` KOSAKI Motohiro
2009-04-07 6:17 ` Brice Goglin
2009-04-07 7:05 ` Andi Kleen
2009-04-07 7:40 ` Brice Goglin
2009-04-07 7:56 ` Andi Kleen
2009-04-07 7:44 ` David Rientjes
2009-04-07 7:59 ` Andi Kleen
2009-04-07 8:08 ` David Rientjes
2009-04-07 8:23 ` Andi Kleen
2009-04-07 8:30 ` David Rientjes
2009-04-07 9:13 ` Andi Kleen
2009-04-03 21:53 ` Andi Kleen
2009-04-03 21:54 ` David Rientjes
2009-04-03 22:18 ` Yinghai Lu
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=87r609jtc2.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.com \
--cc=worleys@gmail.com \
--cc=yhlu.kernel@gmail.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