Cyril Plisko wrote:
> 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.
>
The lu_task_alloc entry point in particular is designed to handle
allocation failures so KM_NOSLEEP there is just using that feature. Its
not a requirement but just an implementation choice. The framework will
work either way but the behavior may be different depending upon what
KM_ flag you use (assuming you really are running out of kernel memory).
Sumit
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
