smbd: High CPU usage

Jeremy Allison jra at
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.


More information about the samba-technical mailing list