Roch - PAE wrote:
> Let's see if I get the facts right:
>
> So the current behavior of fused connections is to call
> tcp_setqfull() from tcp_fuse_output() when there are N
> outstanding writes waiting to be read. The following write()
> will then block until data is read. N is (socket buffer /
> 16K) which equals to 8 out of the box.
>
> When the read thread is the choke point, this will limit the
> size that will be given to each read to be at most "N *
> write size".
>
> This was observed to help an important benchmark because, by
> blocking the writes, it gives more time to the application
> to gather more data for larger subsequent writes (and so
> also larger reads).
>
> The original fuse code was suboptimal because it lead to
> small write & small read and frequent wakeups.
>
> The application works well over a network where Nagle helps
> in making transfers bigger and thus bigger reads (but write
> size are not impacted by Nagle).
I didn't do the actual analysis. But the above is how
I understand the rationale.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
