public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Rogier Wolff <R.E.Wolff@BitWizard.nl>
Cc: adilger@turbolinux.com, linux-kernel@vger.kernel.org,
	zippel@fh-brandenburg.de
Subject: Re: Is sendfile all that sexy? (fwd)
Date: Fri, 19 Jan 2001 15:27:18 +0100	[thread overview]
Message-ID: <20010119152718.C3447@athlon.random> (raw)
In-Reply-To: <200101191058.LAA29762@cave.bitwizard.nl>
In-Reply-To: <200101191058.LAA29762@cave.bitwizard.nl>; from R.E.Wolff@BitWizard.nl on Fri, Jan 19, 2001 at 11:58:03AM +0100

On Fri, Jan 19, 2001 at 11:58:03AM +0100, Rogier Wolff wrote:
> Now if we design the NUMA support correctly, just filling in "disk has
> a seek-time of 10ms, and 20Mb per second throughput when accessed
> linearly" NUMA may on it's own "tune" the swapper to do the right
> thing. And once parametrized like this, we can also handle say a
> leftover piece of framebuffer!

In NUMA we have to deal with RAM and PCI buses that are faster when accessed in
the local node and slower when accessed in a remote node.  Addressing such
single problem is much much less generic than being able to say "plug in this
thing and threat it as memory that goes so fast". I believe we don't need all
such generic interface because it looks quite a bit of overhead, certainly not
at the first approch.

We could easily choose to bind a swap space to a certain node if irqs happens
in the local node and the controller of the disk is attached to a local PCI bus
indeed. But that still has much less generalization than the one you supposed.
And I believe anything that trying to optimize non-RAM backed virtual memory
accesses is worthless because the numa toys have some houndred giga of ram so
you're not going to use anything other than RAM as beckend for virtual
memory...  There are much more worthwhile parts to optimize.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

      reply	other threads:[~2001-01-19 14:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-19 10:58 Is sendfile all that sexy? (fwd) Rogier Wolff
2001-01-19 14:27 ` Andrea Arcangeli [this message]

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=20010119152718.C3447@athlon.random \
    --to=andrea@suse.de \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=adilger@turbolinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zippel@fh-brandenburg.de \
    /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