Add a readv benchmark and fix sketch buffer GC

[talex5]

The benchmark performs 16 concurrent reads of /dev/zero in a loop. Each time a read completes, it issues a new one.

This benchmark unconvered some problems in the current sketch buffer handling:

• A typo in the C stubs meant that the sketch buffer was never released.

• Even with that fixed it might still never be freed, as the application is not required to call submit explicitly. Instead, we now try to release the buffer when waiting or peeking.

• I set the initial sketch buffer size to 4096. Before, it was zero, which lead to quite a lot of allocation as it grows rather slowly. I'm not sure if this really matters, however.

On my machine, I get:

Read 95.37 MB in 0.25 seconds (388.92 MB/second) # buffer_size=100, polling=false
Read 95.37 MB in 0.47 seconds (203.45 MB/second) # buffer_size=100, polling=true
Read 95.37 MB in 0.24 seconds (389.73 MB/second) # buffer_size=100, polling=false
Read 95.37 MB in 0.48 seconds (200.75 MB/second) # buffer_size=100, polling=true

With a larger buffer:

Read 124998.12 MB in 5.11 seconds (24452.64 MB/second) # buffer_size=131072, polling=false
Read 124999.76 MB in 5.14 seconds (24318.08 MB/second) # buffer_size=131072, polling=true
Read 124993.41 MB in 4.95 seconds (25236.34 MB/second) # buffer_size=131072, polling=false
Read 124999.46 MB in 5.17 seconds (24157.28 MB/second) # buffer_size=131072, polling=true

I'm not sure why polling mode is slower. Possibly because reading from /dev/zero doesn't benefit from happing asynchronously.

[haesbaert]

The rationale for checking sq_ready even if dirty was not set, is that technically you can still allocate things and never have dirty set, also more as of a safe guard in the future, checking sq_ready is cheap enough.

[talex5]

OK, I've put it back how it was before.

[haesbaert]

Awesome ! thanks for the fixes \o/