Messages in this thread | | | Date | Fri, 10 Oct 2003 19:26:26 +0900 | From | YoshiyaETO <> | Subject | Re: 2.7 thoughts |
| |
> 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. ---- In the kernel logic, VM mechanics are really orthogonal to the CPU. But, in the real world, someone, like hardware maintenance person, should treat CPUs and memory at a time to maintain Unit. So, notion of Unit should be somewhere, might be sysfs + userland.
> "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 ---- "Forcible" way is not a good idea. In that mean, it should be a "cooperative" way with kernel, userland, and sometimes with system operator who can make an appropriate environment.
> 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 I also expect debate, but not now. I think the way using "ZONE_HIGHTMEM" simplify the issues to be able to remove physical arena other than kernel memory allocated one that would be fixed.
> arena. The two issues mentioned above are in reality non-issues. Could tell me what is the real issue you think?
----- Original Message ----- From: "William Lee Irwin III" <wli@holomorphy.com> To: "YoshiyaETO" <eto@soft.fujitsu.com> Cc: "Stuart Longland" <stuartl@longlandclan.hopto.org>; <linux-kernel@vger.kernel.org>; "Stephan von Krawczynski" <skraw@ithnet.com>; <lgb@lgb.hu>; <Fabian.Frederick@prov-liege.be> Sent: Friday, October 10, 2003 6:09 PM 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/
- 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/
| |