[Pvfs2-developers] tuning kernel buffer settings

Sam Lang slang at mcs.anl.gov
Wed Nov 29 16:51:14 EST 2006


These are great results Phil.  Its nice to have you guys doing this  
testing.  Did you get a chance to run any of your tests with the  
threaded version of pvfs2-client?  I added -threaded option, which  
runs pvfs2-client-core-threaded instead of pvfs2-client-core.  For  
the case where you're running multiple processes concurrently, I  
wonder if you would see some improvement, although Dean didn't see  
any when he tried it with one process doing concurrent reads/writes  
from multiple threads.  Just a thought.

I'd also be curious what affect the mallocs have on performance.  I  
added a fix to Walt's branch for the allocation of all the lookup  
segment contexts on every request from the VFS, but that hasn't  
propagated into HEAD yet.

-sam

On Nov 29, 2006, at 9:58 AM, Phil Carns wrote:

> We recently ran some tests that we thought would be interesting to  
> share.  We used the following setup:
>
> - single client
> - 16 servers
> - gigabit ethernet
> - read/write tests, with 40 GB files
> - using reads and writes of 100 MB each in size
> - varying number of processes running concurrently on the client
>
> This test application can be configured to be run with multiple  
> processes and/or multiple client nodes.  In this case we kept  
> everything on a single client to focus on bottlenecks on that side.
>
> What we were looking at was the kernel buffer settings controlled  
> in pint-dev-shared.h.  By default PVFS2 uses 5 buffers of 4 MB  
> each.  After experimenting for a while, we made a few observations:
>
> - increasing the buffer size helped performance
> - using only 2 buffers (rather than 5) was sufficient to saturate  
> the client when we were running multiple processes; adding more  
> made only a marginal difference
>
> We found good results using 2 32MB buffers.  Here are some  
> comparisons between the standard settings and the 2 x 32MB  
> configuration:
>
> results for RHEL4 (2.6 kernel):
> ------------------------------
> 5 x 4MB, 1 process: 83.6 MB/s
> 2 x 32MB, 1 process: 95.5 MB/s
>
> 5 x 4MB, 5 processes: 107.4 MB/s
> 2 x 32MB, 5 processes: 111.2 MB/s
>
> results for RHEL3 (2.4 kernel):
> -------------------------------
> 5 x 4MB, 1 process: 80.5 MB/s
> 2 x 32MB, 1 process: 90.7 MB/s
>
> 5 x 4MB, 5 processes: 91 MB/s
> 2 x 32MB, 5 processes: 103.5 MB/s
>
>
> A few comments based on those numbers:
>
> - on 3 out of 4 tests, we saw a 13-15% performance improvement by  
> going to 2 32 MB buffers
> - the remaining test (5 process RHEL4) probably did not see as much  
> improvement because we maxed out the network.  In the past, netpipe  
> has shown that we can get around 112 MB/s out of these nodes.
> - the RHEL3 nodes are on a different switch, so it is hard to say  
> how much of the difference from RHEL3 to RHEL4 is due to network  
> topology and how much is due to the kernel version
>
> It is also worth noting that even with this tuning, the single  
> process tests are about 14% slower than the 5 process tests.  I am  
> guessing that this is due to a lack of pipelining, probably caused  
> by two things:
> - the application only submitting one read/write at a time
> - the kernel module itself serializing when it breaks reads/writes  
> into buffer sized chunks
>
> The latter could be addressed by either pipelining the I/O through  
> the bufmap interface (so that a single read or write could keep  
> multiple buffers busy) or by going to a system like Murali came up  
> with for memory transfers a while back that isn't limited by buffer  
> size.
>
> It would also be nice to have a way to set these buffer settings  
> without recompiling- either via module options or via pvfs2-client- 
> core command line options.  For the time being we are going to hard  
> code our tree to run with the 32 MB buffers.  The 64 MB of RAM that  
> this uses up (vs. 20 MB with the old settings) doesn't really  
> matter for our standard node footprint.
>
> -Phil
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>



More information about the Pvfs2-developers mailing list