Re: [PATCH 1/1] network memory allocator.

Evgeniy Polyakov (on Mon, 14 Aug 2006 15:04:03 +0400) wrote:

Network tree allocator can be used to allocate memory for all network
operations from any context....
...
Design of allocator allows to map all node's pages into userspace thus
allows to have true zero-copy support for both sending and receiving
dataflows.

Is that true for architectures with virtually indexed caches?  How do
you avoid the cache aliasing problems?

On Mon, Aug 14, 2006 at 10:07:48PM +1000, Keith Owens (kaos@ocs.com.au) wrote:

Evgeniy Polyakov (on Mon, 14 Aug 2006 15:04:03 +0400) wrote:

quoted

Network tree allocator can be used to allocate memory for all network
operations from any context....
...
Design of allocator allows to map all node's pages into userspace thus
allows to have true zero-copy support for both sending and receiving
dataflows.

Is that true for architectures with virtually indexed caches?  How do
you avoid the cache aliasing problems?

Pages are preallocated and stolen from main memory allocator, what is
the problem with that caches? Userspace can provide enough offset so
that pages would not create aliases - it is usuall mmap.

-- 
	Evgeniy Polyakov

Evgeniy Polyakov wrote:

On Mon, Aug 14, 2006 at 10:07:48PM +1000, Keith Owens (kaos@ocs.com.au) wrote:

quoted

Evgeniy Polyakov (on Mon, 14 Aug 2006 15:04:03 +0400) wrote:

quoted

Network tree allocator can be used to allocate memory for all network
operations from any context....
...
Design of allocator allows to map all node's pages into userspace thus
allows to have true zero-copy support for both sending and receiving
dataflows.

Is that true for architectures with virtually indexed caches?  How do
you avoid the cache aliasing problems?

Pages are preallocated and stolen from main memory allocator, what is
the problem with that caches? Userspace can provide enough offset so
that pages would not create aliases - it is usuall mmap.

That may depend heavily on the architecture.  PA-RISC has the concept of 
spaceid's, and bits from the spaceid can be included in the hash along 
with bits from the offset.  So, it is not possible to simply match the 
offset, one has to make sure that hash bits from the spaceid hash the 
same as well.

Now, PA-RISC CPUs have the ability to disable spaceid hashing, and it is 
entirely possible that the PA-RISC linux port does that, but I thought I 
would mention it as an example.  I'm sure the "official" PA-RISC linux 
folks can expand on that much much better than I can.

rick jones

From: Rick Jones <redacted>
Date: Mon, 14 Aug 2006 10:42:55 -0700

Now, PA-RISC CPUs have the ability to disable spaceid hashing, and it is 
entirely possible that the PA-RISC linux port does that, but I thought I 
would mention it as an example.  I'm sure the "official" PA-RISC linux 
folks can expand on that much much better than I can.

Regardless, the "offset" it usually taken care of transparently
by the kernel in order to avoid cache aliasing issues.

It is definitely something we'll need to deal with for zero-copy
I/O using NTA.  We'll have to make sure that the user mapping of
the page is of the same color as the mapping the kernel uses.