Chris Leech wrote:
Netperf2 TOT now accesses the buffer that was just recv()'d rather than
the one that is about to be recv()'d.
We've posted netperf2 results with I/OAT enabled/disabled and the data
access option on/off at
http://kernel.org/pub/linux/kernel/people/grover/ioat/netperf-icb-1.5-
> Netperf2 TOT now accesses the buffer that was just recv()'d rather than
> the one that is about to be recv()'d.
We've posted netperf2 results with I/OAT enabled/disabled and the data
access option on/off at
http://kernel.org/pub/linux/kernel/people/grover/ioat/netperf-icb-1.5-postscaling-both.pd
On 4/20/06, David S. Miller <[EMAIL PROTECTED]> wrote:
> Yes, and it means that the memory bandwidth costs are equivalent
> between I/O AT and cpu copy.
The following is a response from the I/OAT architects. I only point
out that this is not coming directly from me because I have not seen
the dat
David S. Miller wrote:
> The first thing an application is going to do is touch that data. So
> I think it's very important to prewarm the caches and the only
> straightforward way I know of to always warm up the correct cpu's
> caches is copy_to_user().
Hmm, what if the application is sth. like
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 18:00:37 -0700
Actually, that brings-up a question - presently, and for reasons that
are lost to me in the mists of time - netperf will "access" the buffer
before it calls recv(). I'm wondering if that should
On Thu, Apr 20, 2006 at 08:42:00PM -0700, David S. Miller wrote:
> This is basically why none of the performance gains add up to me. I
> am thus very concerned that the current non-cache-warming
> implmentation may fall flat performance wise.
Ok, I buy your arguments. It does seems unlikely that
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 22:04:26 -0500
> On Thu, Apr 20, 2006 at 05:27:42PM -0700, David S. Miller wrote:
> > Besides the control overhead of the DMA engines, the biggest thing
> > lost in my opinion is the perfect cache warming that a cpu based copy
> > doe
On Thu, Apr 20, 2006 at 05:44:38PM -0700, David S. Miller wrote:
> From: Olof Johansson <[EMAIL PROTECTED]>
> Date: Thu, 20 Apr 2006 18:33:43 -0500
>
> > On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> > > In
> > > addition, there may be workloads (file serving? backup?) where we
On Thu, Apr 20, 2006 at 05:27:42PM -0700, David S. Miller wrote:
> From: Olof Johansson <[EMAIL PROTECTED]>
> Date: Thu, 20 Apr 2006 16:33:05 -0500
>
> > From the wiki:
> >
> > >3. Data copied by I/OAT is not cached
> >
> > This is a I/OAT device limitation and not a global statement of the
David S. Miller <[EMAIL PROTECTED]> wrote:
>
> For I/O AT you'd really want to get the DMA engine going as soon
> as you had those packets, but I do not see a clean and reliable way
> to determine the target pages before the app gets back to recvmsg().
The vmsplice() system call proposed by Linus
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 18:00:37 -0700
> Actually, that brings-up a question - presently, and for reasons that
> are lost to me in the mists of time - netperf will "access" the buffer
> before it calls recv(). I'm wondering if that should be changed to an
>
David S. Miller wrote:
From: "Andrew Grover" <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 15:14:15 -0700
First obviously it's a technology for RX CPU improvement so there's no
benefit on TX workloads. Second it depends on there being buffers to
copy the data into *before* the data arrives. This
Unfortunately, many benchmarks just do raw bandwidth tests sending to
a receiver that just doesn't even look at the data. They just return
from recvmsg() and loop back into it. This is not what applications
using networking actually do, so it's important to make sure we look
intelligently at any
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 18:33:43 -0500
> On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> > In
> > addition, there may be workloads (file serving? backup?) where we
> > could do a skb->page-in-page-cache copy and avoid cache pollution?
>
> Y
From: "Andrew Grover" <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 15:14:15 -0700
> First obviously it's a technology for RX CPU improvement so there's no
> benefit on TX workloads. Second it depends on there being buffers to
> copy the data into *before* the data arrives. This happens to be the
> c
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 16:33:05 -0500
> From the wiki:
>
> >3. Data copied by I/OAT is not cached
>
> This is a I/OAT device limitation and not a global statement of the
> DMA infrastructure. Other platforms might be able to prime caches
> with the DM
On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> Hah, I was just writing an email covering those. I'll incorporate that
> into this reponse.
>
> On 4/20/06, Olof Johansson <[EMAIL PROTECTED]> wrote:
> > I guess the overall question is, how much of this needs to be addressed
> > in
Hah, I was just writing an email covering those. I'll incorporate that
into this reponse.
On 4/20/06, Olof Johansson <[EMAIL PROTECTED]> wrote:
> I guess the overall question is, how much of this needs to be addressed
> in the implementation before merge, and how much should be done when
> more dr
On Thu, Apr 20, 2006 at 01:49:16PM -0700, Andrew Grover wrote:
> Hi I'm reposting these, originally posted by Chris Leech a few weeks ago.
> However, there is an extra part since I broke up one patch that was too
> big for netdev last time into two (patches 2 and 3).
>
> Of course we're always lo
Hi I'm reposting these, originally posted by Chris Leech a few weeks ago.
However, there is an extra part since I broke up one patch that was too
big for netdev last time into two (patches 2 and 3).
Of course we're always looking for more style improvement comments, but
more importantly we're po
20 matches
Mail list logo
