smbd: High CPU usage
Jeremy Allison
jra at samba.org
Wed Jul 18 19:27:04 UTC 2018
On Wed, Jul 18, 2018 at 09:21:43PM +0200, Ralph Böhme wrote:
> On Wed, Jul 18, 2018 at 12:12:05PM -0700, Jeremy Allison via samba-technical wrote:
> > Now all our socket calls are tevent based, I think we should probably
> > change the SMB1 code to match the SMB2 code and make the primary socket
> > non-blocking, then fix the sendfile internal implementation to change to
> > make the socket temporarily blocking, and back to non-blocking after the
> > sendfile completes.
>
> hm, I think we should avoid such hacks. Can't we just somehow go back to the
> event loop if the fd returns EAGAIN or similar for a sendfile() ?
No. The reply may be in a partially sent state.
There's nothing we can do until we've finished sending
the full read reply and there's no internal buffer
to store it as there is with a normal async or sync
read reply.
That's why we have the same hacks in recvfile.
Jeremy.
More information about the samba-technical
mailing list