Re: 2.7 thoughts

[YoshiyaETO <eto@soft.fujitsu.com>]

> 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/