Messages in this thread | | | Date | Fri, 10 Oct 2003 02:09:42 -0700 | From | William Lee Irwin III <> | Subject | Re: 2.7 thoughts |
| |
At some point in the past, I wrote: >> I don't see any reason to connect it with the notion of a node.
On Fri, Oct 10, 2003 at 05:47:37PM +0900, YoshiyaETO wrote: > If the word "Node" is not so appropriate, I will use "Unit". > And I also make it simple, "Unit" will have CPUs and/or Memory. > On the other hand IO-Unit will have IOs.
Well, that's precisely what I was saying was unnecessary. The VM mechanics are orthogonal to the rest, so there's no reason to tie their handling together. The coincidence that they appear bundled on one system or another is irrelevant.
At some point in the past, I wrote: > > The main points of contention would appear to be cooperative vs. > > forcible (where I believe cooperative is acknowledged as the only
On Fri, Oct 10, 2003 at 05:47:37PM +0900, YoshiyaETO wrote: > I could not understand what is forcible. > Everything should be cooperative, I think.
"Forcible" would be "the kernel receives a magic interrupt, and in some mailbox the interrupt handler discovers the memory has either already disappeared or will disappear in some amount of time regardless of whether the kernel is prepared to handle its removal." The distinction is meaningless for the case of onlining. The case of offlining (perhaps by some deadline) is widely considered infeasible, but there are some environments that could consider it desirable.
The bit that was actually expected to spark debate was the ZONE_HIGHMEM notion purported to be a desirable method for resolving the conflict between pinned/wired kernel allocations and cooperative offlining by restricting pinned/wired kernel allocations to some fixed physical arena. The two issues mentioned above are in reality non-issues.
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |