On Thu, Oct 30, 2008 at 8:19 PM, Sumit Gupta <[EMAIL PROTECTED]> wrote:
> Cyril Plisko wrote:
>>
>> On Thu, Oct 30, 2008 at 7:15 PM, Sumit Gupta <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> On Oct 30, 2008, at 9:25 AM, Cyril Plisko wrote:
>>>
>>>
>>>>
>>>> On Thu, Oct 30, 2008 at 6:01 PM, Sumit Gupta <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi Cyril
>>>>>
>>>>> The LU entry points are called using kernel threads (called worker
>>>>> threads
>>>>> inside the framework). The thread pool is dynamically grown from 4 to
>>>>> 256
>>>>> (a
>>>>> soft limit) by stmf based on the load. The task spread is round robin
>>>>> among
>>>>> all the workers. Regarding sleeping, the framework is designed to allow
>>>>> for
>>>>> both synchronous and asynchronous operations. You can choose a model
>>>>> which
>>>>> is best for your application. As a guideline, if you have to sleep for
>>>>> several milliseconds, you should not block the worker thread and use
>>>>> the
>>>>> lu_poll entry point (by calling stmf_task_poll_lu()). But if your sleep
>>>>> is
>>>>> just to implement synchronous operations and your backend is reasonably
>>>>> fast, its ok to block the worker.
>>>>>
>>>>
>>>> Sumit,
>>>>
>>>> thanks for explanation. As for the duration of the sleep - I was
>>>> wondering about calling kmem_alloc() with KM_SLEEP vs KM_NOSLEEP
>>>> inside LU entry point. I have no idea how long this will sleep.
>>>>
>>>
>>> It is ok to use KM_SLEEP inside LU entry points as in most cases
>>> you
>>> will have memory and the call wont sleep. If you are running out of
>>> memory
>>> then your system performance is not going to be good anyway. Which is
>>> what
>>> will happen if the worker sleeps for a long time.
>>>
>>>
>>
>> I see, thanks.
>>
>
> One more thing I forgot to mention is that you should use lu_task_alloc
> entry point to do most of your per-task allocations. The benefit is that
> those allocations are cached by the framework and you wont do them again and
> again for the subsequent tasks. The cache is automatically drained (slowly)
> by stmf (by calling lu_task_free entry point) after few seconds of
> inactivity.
Right. That's what I understood.
BTW in sbd_scsi.c:sbd_task_alloc() - kmem_alloc() is called with
KM_NOSLEEP flag. Any reason to avoid KM_SLEEP here ? In latter case
there wouldn't be any allocation errors to take care of.
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
