* Anthony Liguori [2010-11-01 08:40:36]:
> On 10/26/2010 09:14 AM, Arun R Bharadwaj wrote:
> >+Q.7: Apart from the global pool of threads, can I have my own private Queue
> >?
> >+A.7: Yes, the threadlets framework allows subsystems to create their own
> >private
> >+ queues with associated
On 10/26/2010 09:14 AM, Arun R Bharadwaj wrote:
From: Aneesh Kumar K.V
This patch creates a generic asynchronous-task-offloading infrastructure named
threadlets. The core idea has been borrowed from the threading framework that
is being used by paio.
The reason for creating this generic infrast
On Tue, Oct 26, 2010 at 2:14 PM, Arun R Bharadwaj
wrote:
> From: Aneesh Kumar K.V
>
> This patch creates a generic asynchronous-task-offloading infrastructure named
> threadlets. The core idea has been borrowed from the threading framework that
> is being used by paio.
>
> The reason for creating
From: Aneesh Kumar K.V
This patch creates a generic asynchronous-task-offloading infrastructure named
threadlets. The core idea has been borrowed from the threading framework that
is being used by paio.
The reason for creating this generic infrastructure is so that other subsystems,
such as virt
* Arun R B [2010-10-21 17:40:45]:
> From: Aneesh Kumar K.V
>
> This patch creates a generic asynchronous-task-offloading infrastructure named
> threadlets. The core idea has been borrowed from the threading framework that
> is being used by paio.
>
> The reason for creating this generic infras
From: Aneesh Kumar K.V
This patch creates a generic asynchronous-task-offloading infrastructure named
threadlets. The core idea has been borrowed from the threading framework that
is being used by paio.
The reason for creating this generic infrastructure is so that other subsystems,
such as virt
On 10/19/2010 09:22 PM, Balbir Singh wrote:
OK, here is a situation that can happen
T1 T2
--- ---
threadlet submit_threadletwork_to_queue
(sees condition as no work) mutex_lock
qemu_cond_timedwait add
* Venkateswararao Jujjuri (JV) [2010-10-19 20:46:35]:
> >> I think this is a lot more fragile. You're relying on the fact that
> >> signal will not cause the signalled thread to actually awaken until
> >> we release the lock and doing work after signalling that the
> >> signalled thread needs to
On Tue, Oct 19, 2010 at 6:42 PM, Arun R Bharadwaj
wrote:
> +/**
> + * cancel_threadletwork_on_queue: Cancel a task queued on a Queue.
> + * @queue: The queue containing the task to be cancelled.
> + * @work: Contains the information of the task that needs to be cancelled.
> + *
> + * Returns: 0 if
On 10/19/2010 7:22 PM, Balbir Singh wrote:
> * Anthony Liguori [2010-10-19 16:36:31]:
>
>> On 10/19/2010 01:36 PM, Balbir Singh wrote:
+qemu_mutex_lock(&(queue->lock));
+while (1) {
+ThreadletWork *work;
+int ret = 0;
+
+while (QTAILQ_
On 10/19/2010 2:36 PM, Anthony Liguori wrote:
> On 10/19/2010 01:36 PM, Balbir Singh wrote:
>>> +qemu_mutex_lock(&(queue->lock));
>>> +while (1) {
>>> +ThreadletWork *work;
>>> +int ret = 0;
>>> +
>>> +while (QTAILQ_EMPTY(&(queue->request_list))&&
>>> +
* Venkateswararao Jujjuri (JV) [2010-10-19 14:00:24]:
> >
> > In the case that we just spawned the threadlet, the cond_signal is
> > spurious. If we need predictable scheduling behaviour,
> > qemu_cond_signal needs to happen with queue->lock held.
> >
> > I'd rewrite the function as
> >
> > /
* Anthony Liguori [2010-10-19 16:36:31]:
> On 10/19/2010 01:36 PM, Balbir Singh wrote:
> >>+qemu_mutex_lock(&(queue->lock));
> >>+while (1) {
> >>+ThreadletWork *work;
> >>+int ret = 0;
> >>+
> >>+while (QTAILQ_EMPTY(&(queue->request_list))&&
> >>+ (r
On 10/19/2010 01:36 PM, Balbir Singh wrote:
+qemu_mutex_lock(&(queue->lock));
+while (1) {
+ThreadletWork *work;
+int ret = 0;
+
+while (QTAILQ_EMPTY(&(queue->request_list))&&
+ (ret != ETIMEDOUT)) {
+ret = qemu_cond_timedwait(&(queue->con
On 10/19/2010 11:36 AM, Balbir Singh wrote:
> * Arun R B [2010-10-19 23:12:45]:
>
>> From: Aneesh Kumar K.V
>>
>> This patch creates a generic asynchronous-task-offloading infrastructure
>> named
>> threadlets. The core idea has been borrowed from the threading framework that
>> is being used b
* Arun R B [2010-10-19 23:12:45]:
> From: Aneesh Kumar K.V
>
> This patch creates a generic asynchronous-task-offloading infrastructure named
> threadlets. The core idea has been borrowed from the threading framework that
> is being used by paio.
>
> The reason for creating this generic infras
From: Aneesh Kumar K.V
This patch creates a generic asynchronous-task-offloading infrastructure named
threadlets. The core idea has been borrowed from the threading framework that
is being used by paio.
The reason for creating this generic infrastructure is so that other subsystems,
such as virt
On 10/18/2010 12:47 PM, Arun R Bharadwaj wrote:
* Avi Kivity [2010-10-17 10:57:23]:
> On 10/14/2010 11:32 PM, Venkateswararao Jujjuri (JV) wrote:
> >>
> >> Blocking is somewhat against the spirit of the thing, no? While I
agree that
> >> the current cancel API is hard to use correct
* Avi Kivity [2010-10-17 10:57:23]:
> On 10/14/2010 11:32 PM, Venkateswararao Jujjuri (JV) wrote:
> >>
> >> Blocking is somewhat against the spirit of the thing, no? While I agree
> >> that
> >> the current cancel API is hard to use correctly, blocking defeats the
> >> purpose of
> >> the
On 10/14/2010 11:32 PM, Venkateswararao Jujjuri (JV) wrote:
>
> Blocking is somewhat against the spirit of the thing, no? While I agree that
> the current cancel API is hard to use correctly, blocking defeats the
purpose of
> the API.
>
Are you proposing to add additional state in the retur
On 10/15/2010 2:52 AM, Stefan Hajnoczi wrote:
> On Thu, Oct 14, 2010 at 10:17 PM, Venkateswararao Jujjuri (JV)
> wrote:
>> On 10/14/2010 2:02 AM, Stefan Hajnoczi wrote:
>>> On Wed, Oct 13, 2010 at 4:31 PM, Arun R Bharadwaj
+static void *threadlet_worker(void *data)
+{
+Threadlet
On Thu, Oct 14, 2010 at 10:17 PM, Venkateswararao Jujjuri (JV)
wrote:
> On 10/14/2010 2:02 AM, Stefan Hajnoczi wrote:
>> On Wed, Oct 13, 2010 at 4:31 PM, Arun R Bharadwaj
>>> +static void *threadlet_worker(void *data)
>>> +{
>>> + ThreadletQueue *queue = data;
>>> +
>>> + qemu_mutex_lock(&(q
On Thu, Oct 14, 2010 at 5:16 PM, Avi Kivity wrote:
> On 10/14/2010 11:15 AM, Stefan Hajnoczi wrote:
>>
>> I forgot to add that the semantics of cancellation make it difficult
>> to write correct user code. Every cancellation user needs to add
>> extra synchronization after the cancel call to han
On 10/14/2010 9:16 AM, Avi Kivity wrote:
> On 10/14/2010 11:15 AM, Stefan Hajnoczi wrote:
>> I forgot to add that the semantics of cancellation make it difficult
>> to write correct user code. Every cancellation user needs to add
>> extra synchronization after the cancel call to handle the case w
On 10/14/2010 2:02 AM, Stefan Hajnoczi wrote:
> On Wed, Oct 13, 2010 at 4:31 PM, Arun R Bharadwaj
> wrote:
>> From: Aneesh Kumar K.V
>>
>> This patch creates a generic asynchronous-task-offloading infrastructure
>> named
>> threadlets. The core idea has been borrowed from the threading framework
On 10/14/2010 11:15 AM, Stefan Hajnoczi wrote:
I forgot to add that the semantics of cancellation make it difficult
to write correct user code. Every cancellation user needs to add
extra synchronization after the cancel call to handle the case where
the work is currently executing.
This seems
On Thu, Oct 14, 2010 at 10:15:30AM +0100, Stefan Hajnoczi wrote:
> I forgot to add that the semantics of cancellation make it difficult
> to write correct user code. Every cancellation user needs to add
> extra synchronization after the cancel call to handle the case where
> the work is currently
I forgot to add that the semantics of cancellation make it difficult
to write correct user code. Every cancellation user needs to add
extra synchronization after the cancel call to handle the case where
the work is currently executing.
This seems tricky to me and I suspect code using this interfa
On Wed, Oct 13, 2010 at 4:31 PM, Arun R Bharadwaj
wrote:
> From: Aneesh Kumar K.V
>
> This patch creates a generic asynchronous-task-offloading infrastructure named
> threadlets. The core idea has been borrowed from the threading framework that
> is being used by paio.
>
> The reason for creating
* Arun R Bharadwaj [2010-10-13 22:14:39]:
commit 1fb4801768722016cd6ec9bbf1271c69b37df2a2
Author: Aneesh Kumar K.V
Date: Tue Oct 12 14:06:10 2010 +0530
Introduce threadlets
This patch creates a generic asynchronous-task-offloading infrastructure
named
threadlets. The core id
From: Aneesh Kumar K.V
This patch creates a generic asynchronous-task-offloading infrastructure named
threadlets. The core idea has been borrowed from the threading framework that
is being used by paio.
The reason for creating this generic infrastructure is so that other subsystems,
such as virt
31 matches
Mail list logo
