hi, > Ok, this is different. I had missed that you are talking > about a small device with slow memory bandwith. In that > case, you might certainly gain something by avoiding the > copies. If you are really memcpy-bound, you should > definitely make splice work.
yes, but the question is by how much can it improve. We would like to see it reach 7Mbps in 2 or 3 months, can't just waiting for linux kernel fix the problem. Is there any individuals/company capable of doing such performance improvement for charge? > At the high end, latencies is mostly what kills your > performance. Mostly you have enough bandwidth, but if you > just do a simple request->response scheme, you can't get > beyond a certain overall bandwith that is way below the > theoretical network bandwith. To fill that, you need to make > the client issue parallel requests. Multi-threaded windows > client apps can do it, smbclient from 3.2 does it. I have tried multiple threads but it doesn't help the performance in my case. The delay caused by memory copy seems dominate. Best Regards, Mac Lin> Date: Fri, 12 Sep 2008 09:45:32 +0200 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED]; [email protected] > Subject: Re: [Samba] Samba write performance in kernel > > On Fri, Sep 12, 2008 at 02:43:25PM +0800, Lin Mac wrote: > > well, in my condition, it might be 30% instead of 5%, IF > > splice can cover advantage 1 and 2. > > 1. I'm using a slow CPU (FA526) , and the memory copy is even slower. > > 2. The reading performance is over 7 MB/s, with mmap and > > sendfile enabled, while writing is only 4-5 MB/s. Without > > mmap and sendfile, reading from samba is also about 4-5 > > MB/s. > > 3. I used Oprofile to profile writing file to samba and > > found that CPU takes over 30% CPU time on > > copy_from/to_user, so I think going to user space and back > > again is the bottleneck. > > 4. My device is only 100Mbps Ethernet > > 5. I uses Windows client to measure throughput > > Ok, this is different. I had missed that you are talking > about a small device with slow memory bandwith. In that > case, you might certainly gain something by avoiding the > copies. If you are really memcpy-bound, you should > definitely make splice work. > > > > here, but the network latencies together with non-optimally > > > queued requests by the client have a MUCH greater influence. > > 1. If splice works, can memory copy be avoided? > > 2. Sorry I don't really get what the "non-optimally queued > > requests" means. And what could I do to make it optimized? > > At the high end, latencies is mostly what kills your > performance. Mostly you have enough bandwidth, but if you > just do a simple request->response scheme, you can't get > beyond a certain overall bandwith that is way below the > theoretical network bandwith. To fill that, you need to make > the client issue parallel requests. Multi-threaded windows > client apps can do it, smbclient from 3.2 does it. > > Volker _________________________________________________________________ 聰明搜尋和瀏覽網路的免費工具列 — MSN 搜尋工具列 http://toolbar.live.com/ -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
