smbd: High CPU usage

[Ralph Böhme]

On Wed, Jul 18, 2018 at 01:56:43PM -0700, Jeremy Allison 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.
>
>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.

yeah, I get your point, it just feels so clumsy. :)))

-slow

-- 
Ralph Boehme, Samba Team       https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG Key Fingerprint:           FAE2 C608 8A24 2520 51C5
                               59E4 AA1E 9B71 2639 9E46