Zero-copy patch

[Jacky Lam]

Jeremy,

	I try again the patch on my MIPS platform and happily find that the throughput improves by 20%. However, I get some data corruption. I find there is some chance the order of two 64K data packets is reversed. Who is the author of this patch? Need to submit the bug to him?

	Thanks.

BR,
Jacky

> -----Original Message-----
> From: samba-technical-bounces at lists.samba.org [mailto:samba-technical-
> bounces at lists.samba.org] On Behalf Of Jacky Lam
> Sent: Thursday, February 10, 2011 2:29 PM
> To: Jeremy Allison
> Cc: Volker.Lendecke at SerNet.DE; samba-technical at lists.samba.org
> Subject: RE: Zero-copy patch
> 
> 
> 
> > -----Original Message-----
> > From: Jeremy Allison [mailto:jra at samba.org]
> > Sent: Thursday, February 10, 2011 9:43 AM
> > To: Jacky Lam
> > Cc: Jeremy Allison; Volker.Lendecke at SerNet.DE; samba-
> > technical at lists.samba.org
> > Subject: Re: Zero-copy patch
> >
> > On Tue, Feb 08, 2011 at 01:53:14AM -0500, Jacky Lam wrote:
> > > Jeremy,
> > >
> > >         After tracing the kernel code, I come up with a
> disappointing
> > conclusion.
> > >
> > >         The heavy memory copy are coming from two places in kernel:
> > >
> > >         1. net/core/skbuff.c: linear_to_page()
> > >         2. fs/splice.c: pipe_to_file()
> > >
> > >         The first one is actually introduced in 2.6.28.6/2.6.29 to
> > fix a data corruption bug when splice from socket to socket. I quote
> > the kernel change log at the end of mail. This one seems don't bother
> > Samba, so I roll back the fix and get a 10% improvement.
> > >
> > >         The second one do memcopy when
> > >                 *       Destination page already exists in the
> > address space and there
> > >                 *       are users of it. For that case we have no
> > other option that
> > >                 *       copying the data. Tough luck.
> > >         But I am curious who the users are (mistake?). So, I just
> > comment out the memory copy and expect data corruption. I want to
> check
> > what can I achieve if all these things are probably fixed.
> > >
> > >         Finally, I get the throughput more or less the same as
> using
> > read()/write(). It doesn't worthwhile to bother all those trouble at
> > all. Maybe the data flow of current implementation of socket splice
> are
> > inefficient enough indeed.
> > >
> > >         If there is not any other idea, I think I would rather
> spend
> > time on how to make the patches you send me to work.
> >
> > Another OEM (who shall remain nameless) mentioned
> > that changing the kernel scheduler to the deadline
> > scheduler helps performance (you may already have
> > done this of course).
> >
> > Let me know if you haven't and if it helps.
> >
> > Jeremy.
> 
> I have tried before and just now again. No noticeable changes.
> 
> BTW, I applied the patch to kernel of my desktop. The patch is applied
> cleanly but obviously missing something. It add
> splice_direct_from_socket() for splice(), but have nothing change for
> sendfile(). Anyway, I do a quick fix for that and finally got sendfile()
> do what we want. The result is the throughput is about 5% faster than
> read/write implementation. But it is far lower than my expectation. Is
> this reported result of the patch?
> 
> Jacky
> 
> 
> IMPORTANT CONFIDENTIALITY NOTICE
> This message and any attached documents contain information from ViXS
> Systems, Inc. and are confidential and privileged and further subject
> to any confidentiality agreement between the parties. The information
> is intended to be viewed only by the individual(s) or entity(ies) to
> whom the message is addressed. If you are not the intended recipient,
> be aware that reading, disclosing, copying, distributing or using the
> contents of this transmission is prohibited. Please notify us
> immediately if you have received this transmission in error, and delete
> this message along with any attached files.