smbd: High CPU usage

[Jeremy Allison]

On Wed, Jul 18, 2018 at 10:57:27PM +0200, Ralph Böhme wrote:
> 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.
> 
> ...and let smbd_smb2_flush_send_queue() return NT_STATUS_OK at the end of "if
> (e->sendfile_header != NULL)".

I've been thinking about it more, and adding immediate
events here is only a more complex way of spinning on
the CPU :-). Once we've gotten EAGAIN on the sendfile
there's nothing we can do until the socket drains some.
We can't safely do anything else.

> But honestly, I have no idea what I'm talking about as I've successfully avoided
> looking into the sendfile code path at the SMB2 layer until now. It makes such a
> mess out of the simple fde based event handling, we should remove it. :)

Yes, it was a solution to blocking IO with SMB1.

It's useful for low-end hardware that can't handle
multiple threads/context switches though, so
fixing it underneath the covers so it *looks* like
it copes well with non-blocking IO is a "good-enough"
solution IMHO.

I'll log a bug and fix all the vendor-specific sendfile()
implementations to do the save_flags/set_blocking/sendfile/restore_flags
dance inside source3/lib/sendfile.c so no one else has
to know about it :-).

Jeremy.