public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
Subject: Re: 2.7 thoughts
Date: Fri, 10 Oct 2003 02:09:42 -0700	[thread overview]
Message-ID: <20031010090942.GC700@holomorphy.com> (raw)
In-Reply-To: <04d501c38f0b$2864c210$6a647c0a@eto>

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

  reply	other threads:[~2003-10-10  9:07 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-09  8:08 2.7 thoughts Frederick, Fabian
2003-10-09  8:55 ` John Bradford
2003-10-09  9:45   ` mario noioso
2003-10-09 11:58 ` Gábor Lénárt
2003-10-09 14:57   ` Stephan von Krawczynski
2003-10-10  6:19     ` Stuart Longland
2003-10-10  6:30       ` William Lee Irwin III
2003-10-10  7:30         ` YoshiyaETO
2003-10-10  7:40           ` William Lee Irwin III
2003-10-10  8:47             ` YoshiyaETO
2003-10-10  9:09               ` William Lee Irwin III [this message]
2003-10-10 10:26                 ` YoshiyaETO
2003-10-10 10:50                   ` William Lee Irwin III
2003-10-10 10:55                     ` William Lee Irwin III
2003-10-10 10:51       ` Stephan von Krawczynski
2003-10-10 14:07         ` Stuart Longland
2003-10-10 14:27           ` Stephan von Krawczynski
2003-10-10 14:35           ` Gábor Lénárt
2003-10-10 14:47             ` William Lee Irwin III
2003-10-10 14:48               ` Mark Mielke
2003-10-10 15:01                 ` William Lee Irwin III
2003-10-10 15:50                   ` Mark Mielke
2003-10-10 16:35                     ` Chris Friesen
2003-10-10 16:44                       ` William Lee Irwin III
2003-10-12 20:14                   ` Pavel Machek
2003-10-10 15:12               ` Jamie Lokier
2003-10-10 15:21                 ` William Lee Irwin III
2003-10-10 18:03               ` Tim Hockin
2003-10-10 18:29                 ` William Lee Irwin III
2003-10-10 18:56                   ` Tim Hockin
2003-10-10 23:40                     ` Rusty Russell
2003-10-15 19:15           ` Anton Blanchard
2003-10-10 13:30       ` Kevin Corry
2003-10-10 18:29         ` Lars Marowsky-Bree
2003-10-11  3:49           ` jw schultz
2003-10-11 13:24             ` Lars Marowsky-Bree
2003-10-11 19:50               ` jw schultz
2003-10-10 17:12       ` Matt Simonsen
2003-10-10 20:59   ` Pedro Larroy
2003-10-09 18:17 ` Greg KH
2003-10-09 19:07 ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2003-10-09 11:56 Svetoslav Slavtchev
2003-10-09 12:44 Xose Vazquez Perez
2003-10-09 13:17 Frederick, Fabian
2003-10-09 13:19 ` Jens Axboe
2003-10-09 13:50 ` Gábor Lénárt
2003-10-09 13:52 ` Bartlomiej Zolnierkiewicz
2003-10-10 19:01 Zwane Mwaikambo

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=20031010090942.GC700@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=Fabian.Frederick@prov-liege.be \
    --cc=eto@soft.fujitsu.com \
    --cc=lgb@lgb.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=skraw@ithnet.com \
    --cc=stuartl@longlandclan.hopto.org \
    /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