| To: | "William J. Earl" <wje@fir.engr.sgi.com>, Alex deVries <adevries@engsoc.carleton.ca>, Igor Loncarevic <anubis@BanjaLuka.NET>, SGI Linux <linux@cthulhu.engr.sgi.com> |
|---|---|
| Subject: | Re: What about... |
| From: | "Greg Chesson" <greg@xtp.engr.sgi.com> |
| Date: | Fri, 17 Jul 1998 10:47:02 -0700 |
| In-reply-to: | "William J. Earl" <wje@fir> "Re: What about..." (Jul 17, 7:11am) |
| References: | <Pine.LNX.3.95.980717012356.5792A-100000@lager.engsoc.carleton.ca> <adevries@engsoc.carleton.ca> <9807162230.ZM17359@xtp.engr.sgi.com> <199807171411.HAA11412@fir.engr.sgi.com> |
| Sender: | owner-linux@cthulhu.engr.sgi.com |
Bill is, of course, quite correct. In addition to the observations about the scale of the system, realize also that a ccNUMA machine has a memory system for each cpu node in the system. The physical base addresses of these blocks of memory are aligned on multi-gigabyte boundaries. The high-order bits of the address designate the cpu node, the rest address the physical memory, etc etc. What this means is that physical memory space has many "holes"... The idea of a simple buddy-system allocator as is ingrained in the Linux kernel falls apart completely in the face of this kind of architecture. I suppose you could run a copy of Linux on every node, but I consider that an excuse rather than a solution. g -- Greg Chesson |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: What about..., ralf |
|---|---|
| Next by Date: | Re: What about..., Alan Cox |
| Previous by Thread: | Re: What about..., Greg Chesson |
| Next by Thread: | Re: What about..., Alan Cox |
| Indexes: | [Date] [Thread] [Top] [All Lists] |