[sheepdog] [PATCH] sheep: introduce 'short thread' to worker threads

[Liu Yuan]

On 07/04/2012 12:50 AM, Christoph Hellwig wrote:
> On Wed, Jul 04, 2012 at 12:47:08AM +0800, Liu Yuan wrote:
>> What is consequence of 'hit the kernel really hard'? overhead of clone()
>> system call? For thread pool, we also hit hard on mutex(futex) and
>> pthread condition.
> 
> I just know that this naive use showed problems in previous projects
> I did a few years ago.

It depends how you define 'naive'. Pthreads internally does a lot of
caching tricks like malloc(), which many people are biased on its
performance and write slab-like allocator on top it for in-house APP,
which sometimes ironically in fact shows worse performance.

I know it is implementation related and malloc() is not a good argument,
but I want to state that, simple pooling are not necessarily smarter
than glibc's default implementation.

> 
>>> We'll at least need to keep a pool of available threads around.
>>>
>>
>> It is not hard to implement it, but do we really need threads pool? And
>> more importantly, why? I think kernel's thread model is capable of
>> handling frequent thread creation and destroying in terms of task_struct
>> and kernel stack for thread. Also pthreads has internal resource
>> pooling, so speaking about performance, I don't think it is not inferior
>> compared to static thread pool.
> 
> Please provide numbers - fundamental changes like this should come with
> extensive benchmark numbers.  I'll try to get some myself, but with the
> next release coming up soon I need to finish up the versioning changes.
> 

Yes, I need numbers, I tried and didn't get useful numbers, the threads
are doing IO which occupy most of the execution time , the difference is
actually not that easy to be caught.

Thanks,
Yuan