jlam at vixs.com
Thu Feb 10 20:39:44 MST 2011
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?
> -----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
> > 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 188.8.131.52/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
> > what can I achieve if all these things are probably fixed.
> > >
> > > Finally, I get the throughput more or less the same as
> > read()/write(). It doesn't worthwhile to bother all those trouble at
> > all. Maybe the data flow of current implementation of socket splice
> > inefficient enough indeed.
> > >
> > > If there is not any other idea, I think I would rather
> > 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?
> 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.
More information about the samba-technical