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.
>
>> I also didn't quite grok your note on using lu_poll. Can you please
>> give some example ?
>
> The framework provides a mechanism for the LU to say "I cannot handle
> this task right now, call me back later". The LU does so by calling
> stmf_task_poll_lu() and the framework later on calls the lu_poll entry
> point. This is useful for very slow tasks like rewinding a tape or ejecting
> media etc. This is also documented in detail in the stmf spec.
I think I need to spend some more time with the spec. BTW, v1.4 that
is published on os.org - is it the latest spec ?
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
