From: Rob Landley <landley@trommello.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: riel@conectiva.com.br (Rik van Riel), linux-kernel@vger.kernel.org
Subject: Re: Whining about NUMA. :) [Was whining about 2.5...]
Date: Thu, 4 Oct 2001 19:59:00 -0400 [thread overview]
Message-ID: <01100419590005.02393@localhost.localdomain> (raw)
In-Reply-To: <E15pFUQ-00045y-00@the-village.bc.nu>
In-Reply-To: <E15pFUQ-00045y-00@the-village.bc.nu>
On Thursday 04 October 2001 16:53, Alan Cox wrote:
> > Is there really a NUMA machine out there where you can DMA out of another
> > node's 16 bit ISA space? So far the differences in the zones seem to be
>
> DMA engines are tied to the node the device is tied to not to the processor
> in question in most NUMA systems.
Oh good. I'd sort of guessed that part, but wasn't quite sure. (I've seen
hardware people do some amazingly odd things before. Luckily not recently,
though...)
So would a workable (if naieve) attempt to use Andrea's
memory-zones-grouped-into-classes approach on NUMA just involve making a
class/zone list for each node? (Okay, you've got to identify nodes, and
group together processors, bridges, DMAable devices, etc, but it seems like
that has to be done anyway, class/zone or not.) How does what people want to
do for NUMA improve on that?
Is a major goal of NUMA figuring out how to borrow resources from adjacent
nodes (and less-adjacent nodes) in a "second choice, third choice, twelfth
choice" kind of way? Or is a "this resource set is local to this node, and
allocating beyond this group is some variant of swapping behavior" approach
an acceptable first approximation?
If class/zone is so evil for NUMA, what's the alternative that's being
considered? (Pointer to paper?)
I'm wondering how the class/zone approach is more evil than the alternative
of having lots and lots of little zones which have different properties for
each processor and DMAable device on the system, and then trying to figure
out what to do from there at allocation time or during each attempt to
inflict I/O upon buffers.
Rob
P.S. Rik pointed out in email (replying to my "master of stupid questions"
signoff) that I am indeed confused about a great many things, but didn't
elaborate. Of course I agree with this, but I do try to make it up on volume
:).
next prev parent reply other threads:[~2001-10-05 6:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-03 12:17 bug? in using generic read/write functions to read/write block devices in 2.4.11-pre2 Vladimir V. Saveliev
2001-10-03 13:16 ` [PATCH] " Alexander Viro
2001-10-03 16:18 ` Linus Torvalds
2001-10-03 21:43 ` Alexander Viro
2001-10-03 21:56 ` Christoph Hellwig
2001-10-03 22:51 ` Alexander Viro
2001-10-03 19:55 ` Whining about 2.5 (was Re: [PATCH] Re: bug? in using generic read/write functions to read/write block devices in 2.4.11-pre2) Rob Landley
2001-10-04 0:38 ` Rik van Riel
2001-10-03 22:27 ` Rob Landley
2001-10-04 20:53 ` Whining about 2.5 (was Re: [PATCH] Re: bug? in using generic read/write functions to read/write block devices in 2.4.11-pre2O Alan Cox
2001-10-04 23:59 ` Rob Landley [this message]
2001-10-05 14:51 ` Whining about NUMA. :) [Was whining about 2.5...] Alan Cox
2001-10-08 17:57 ` Martin J. Bligh
2001-10-08 18:10 ` Alan Cox
2001-10-08 18:20 ` Martin J. Bligh
2001-10-08 18:31 ` Alan Cox
2001-10-08 18:35 ` Jesse Barnes
2001-10-08 18:55 ` Martin J. Bligh
2001-10-08 17:48 ` Marcelo Tosatti
2001-10-08 19:20 ` Martin J. Bligh
2001-10-08 19:12 ` Jesse Barnes
2001-10-08 19:37 ` Peter Rival
2001-10-04 23:39 ` NUMA & classzones (was Whining about 2.5) Martin J. Bligh
2001-10-04 23:55 ` Rob Landley
2001-10-05 17:29 ` Martin J. Bligh
2001-10-06 1:44 ` Jesse Barnes
2001-10-04 21:02 ` Whining about 2.5 (was Re: [PATCH] Re: bug? in using generic read/write functions to read/write block devices in 2.4.11-pre2) Alan Cox
2001-10-03 21:09 ` Buffer cache confusion? Re: [reiserfs-list] bug? in using generic read/write functions to read/write block devices in 2.4.11-pre2 Eric Whiting
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=01100419590005.02393@localhost.localdomain \
--to=landley@trommello.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
/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