public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jeff V. Merkey" <jmerkey@vger.timpanogas.org>
To: Pauline Middelink <middelin@polyware.nl>,
	linux-kernel@vger.kernel.org, jmerkey@timpanogas.org
Cc: jmerkey@timpanogas.org
Subject: Re: bigphysarea support in 2.2.19 and 2.4.0 kernels
Date: Fri, 22 Dec 2000 11:11:05 -0700	[thread overview]
Message-ID: <20001222111105.B14232@vger.timpanogas.org> (raw)
In-Reply-To: <20001221144247.A10273@vger.timpanogas.org> <E149DKS-0003cX-00@the-village.bc.nu> <20001221154446.A10579@vger.timpanogas.org> <20001221155339.A10676@vger.timpanogas.org> <20001222093928.A30636@polyware.nl>
In-Reply-To: <20001222093928.A30636@polyware.nl>; from middelink@polyware.nl on Fri, Dec 22, 2000 at 09:39:28AM +0100

On Fri, Dec 22, 2000 at 09:39:28AM +0100, Pauline Middelink wrote:
> On Thu, 21 Dec 2000 around 15:53:39 -0700, Jeff V. Merkey wrote:
> > 
> > Alan,
> > 
> > I am looking over the 2.4 bigphysarea patch, and I think I agree 
> > there needs to be a better approach.  It's a messy hack -- I agree.
> 
> Please explain further.
> Just leaving it at that is not nice. What is messy?
> The implementation? The API?
> 
> If you have a better solutions for allocating big chunks of
> physical continious memory at different stages during the
> runtime of the kernel, i would be very interesseted.
> 
> (Alan: bootmem allocation just won't do. I need that memory
> in modules which get potentially loaded/unloaded, hence a
> wrapper interface for allowing access to a bootmem allocated
> piece of memory)
> 
> And the API? That API was set a long time ago, luckely not by me :)
> Though I dont see the real problem. It allows allocation and
> freeing of chunks of memory. Period. Its all its suppose to do.
> Or do you want it rolled in kmalloc? So GFP_DMA with size>128K
> would take memory from this? That would mean a much more intrusive
> patch in very sensitive and rapidly changing parts of the kernel
> (2.2->2.4 speaking)...
> 
>     Met vriendelijke groet,
>         Pauline Middelink

Pauline,

Can we put together a patch that meets Alan's requirements and get it into 
the kernel proper.  We have taken on a project from Dolphin to merge the
high speed Dolphin SCI interconnect drivers into the kernel proper, and 
obviously, it's not possible to do so if the drivers are dependent on 
this patch.  I can send you the driver sources for the SCI cards, at 
least the portions that depend on this patch, and would appreciate
any guidance you could provide on a better way to allocate memory.

SCI allows machines to create windows of shared memory across a cluster
of nodes, and at 1 Gigabyte-per-second (Gigabyte not gigabit).  I am
putting a sockets interface into the drivers so Apache, LVS, and 
Pirahna can use these very high speed adapters for a clustered web 
server.  Our M2FS clustered file system also is being architected 
to use these cards.  

I will post the source code for the SCI cards at vger.timpanogas.org 
and if you have time, please download this code and take a look at 
how we are using the bigphysarea APIs to create these windows accros
machines.  The current NUMA support in Linux is somewhat slim, and 
I would like to use established APIs to do this if possible.

:-)

Jeff
 


> -- 
> GPG Key fingerprint = 2D5B 87A7 DDA6 0378 5DEA  BD3B 9A50 B416 E2D0 C3C2
> For more details look at my website http://www.polyware.nl/~middelink
-
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/

  parent reply	other threads:[~2000-12-22 17:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-21 21:42 bigphysarea support in 2.2.19 and 2.4.0 kernels Jeff V. Merkey
2000-12-21 21:32 ` Alan Cox
2000-12-21 22:44   ` Jeff V. Merkey
2000-12-21 22:53     ` Jeff V. Merkey
2000-12-22  8:39       ` Pauline Middelink
2000-12-22  8:58         ` Alan Cox
2000-12-22 23:11           ` Albert D. Cahalan
2000-12-23  8:40             ` Eric W. Biederman
2000-12-24  8:59               ` Albert D. Cahalan
2000-12-23 20:11             ` Jes Sorensen
2000-12-24  8:15               ` Albert D. Cahalan
2000-12-22 18:11         ` Jeff V. Merkey [this message]
2000-12-22 18:35           ` Jeff V. Merkey
2000-12-22 19:21             ` Andi Kleen
2000-12-22 20:25               ` Jeff V. Merkey
2000-12-22 19:51                 ` Pauline Middelink
2000-12-22 21:54                   ` Jeff V. Merkey
2000-12-22 21:39                     ` Erik Mouw
2000-12-22 23:56                       ` Jeff V. Merkey
2000-12-22 19:37           ` NUMA and SCI [was Re: bigphysarea support in 2.2.19 and 2.4.0 kernels] Tim Wright
2000-12-22 20:39             ` Jeff V. Merkey
2000-12-22 20:30               ` Alan Cox
2000-12-22 21:40                 ` Jeff V. Merkey
2000-12-22 21:52                   ` Jeff V. Merkey

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=20001222111105.B14232@vger.timpanogas.org \
    --to=jmerkey@vger.timpanogas.org \
    --cc=jmerkey@timpanogas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=middelin@polyware.nl \
    /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