threads and VMS [Re: dce/rpc "client" api]

Bob Mastors mastors at
Thu Aug 24 17:09:58 GMT 2000

----- Original Message ----- 
From: Andrew Tridgell <tridge at>
To: <mastors at>
Cc: <jeremy at>; <lkcl at>; <samba-technical at>
Sent: Wednesday, August 23, 2000 7:30 PM
Subject: Re: threads and VMS [Re: dce/rpc "client" api]

> Bob,
> I'm not convinced that multi-threading smbd would actually give a
> performance improvement, even for artificial things like netbench.
I agree there is not convincing evidence for multi-threading to
gain performance. In our kernel implementation of the cifs protocol
we implemented a multi-threaded architecture because it made
oplocks and transaction commands easier to implement. Performance
concerns were secondary.

Performance tuning is not always straight forward of course.
It is too easy to optimize a system for one benchmark at the
expense of some other benchmark. And there is no such thing as
a "real world" benchmark because we all live in different worlds.

Still if I were doing it over again I would multi-thread our
smb server. Multi-thread programming is much more fun.


> Although on the surface it might seem obvious it is not at all obvious
> when you dig a bit deeper.
> Here's why:
> - only two types of operations take enough time that it would be worth
>   trying to process another SMB while waiting. They are reads and
>   blocking locks. (I'm ignoring printing here for now, see my earlier
>   email about printing and threads). Note in particular that I do not
>   include writes in this list, that's because a modern OS returns on a
>   write pretty much immediately. All the kernel does is copy the data
>   into the page cache and then the actual disk IO happens
>   asynchronously.
> - for blocking locks smbd currently pushes the lock request onto a
>   list of pending blocking locks and continues processing with the
>   next packet on the socket (see push_blocking_lock_request()). So for
>   those we are already "multi-threaded".
> - for reads we are not multi-threaded. Does it matter? If the data is
>   coming from the page cache then probably not (unless our network
>   bandwidth is nearly as large as our memory bandwidth). If the data
>   is coming from disk then we could gain something if there are other
>   requests pending on the same socket that could be satisfied without
>   a disk read, or with a disk read on a different disk spindle.
> - the above all assumes a single client. Now what happens when we
>   are serving a dozen or (as happens in a netbench run) hundreds of
>   clients? You only gain when you multi-thread if your your single
>   threaded system doesn't have anything useful to do while waiting for
>   a read to complete. When there are large numbers of clients this is
>   unlikely.
> It may be that adding something like push_blocking_read_request()
> combined with aio_read() (which is how we'd have to implement IO
> threading in Samba) is a worthwhile addition, but I don't think it is
> obvious that it will be a win. If anyone wants to investiage this then
> start by writing a simulator (use tbench as a basis if you like - it
> simulates the current Samba code) and write some tests against the
> simulator to see if we really gain anything.
> Cheers, Tridge

More information about the samba-technical mailing list