smbd: High CPU usage

[Jeremy Allison]

On Wed, Jul 18, 2018 at 10:34:43PM +0200, Ralph Böhme wrote:
> On Wed, Jul 18, 2018 at 12:27:04PM -0700, Jeremy Allison wrote:
> > 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.
> 
> hm, if you implement sendfile_send() with immediate events I guess that will
> have higher priority then the out queue processing of SMBX response PDUs. Just
> braindumping here, I'd have to take a closer look.

Don't want to risk those changes. sendfile() is a
somewhat deprecated API now we have proper async
pthreaded IO, so I'm OK with my patch changing the
socket state to blocking and back for each sendfile
call.

Jeremy.