threadpool: Add cancel() function

When resetting a virtqueue, it is often necessary to make sure that the
associated threadpool job isn't running anymore. Add a function to
cancel a job.

A threadpo

threadpool: Add cancel() function

When resetting a virtqueue, it is often necessary to make sure that the
associated threadpool job isn't running anymore. Add a function to
cancel a job.

A threadpool job has three states: idle, queued and running. A job is
queued when it is in the job list. It is running when it is out the
list, but its signal count is greater than zero. It is idle when it is
both out of the list and its signal count is zero. The cancel() function
simply waits for the job to be idle. It is up to the caller to make sure
that the job isn't queued concurrently.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvm tools: use mutex abstraction instead of pthread mutex

We already have something to wrap pthread with mutex_[init,lock,unlock]
calls. This patch creates a new struct mutex abstraction and moves
e

kvm tools: use mutex abstraction instead of pthread mutex

We already have something to wrap pthread with mutex_[init,lock,unlock]
calls. This patch creates a new struct mutex abstraction and moves
everything to work with it.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: threadpool exit routine

Add an exit function for the threadpool which will stop all running threads in the
pool. Also clean up the init code a bit.

Signed-off-by: Sasha Levin <levinsasha

kvm tools: threadpool exit routine

Add an exit function for the threadpool which will stop all running threads in the
pool. Also clean up the init code a bit.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Don't dynamically allocate threadpool jobs

To allow efficient use of shorter-term threadpool jobs, don't
allocate them dynamically upon creation. Instead, store them
within 'job' structur

kvm tools: Don't dynamically allocate threadpool jobs

To allow efficient use of shorter-term threadpool jobs, don't
allocate them dynamically upon creation. Instead, store them
within 'job' structures.

This will prevent some overhead creating/destroying jobs which live
for a short time.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Abolishment of uint*_t types

Clean uint*_t type from the code.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

kvm tools: Modify thread pool API

Modify API function names and type names.

[ penberg@kernel.org: drop virtio net parts ]
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka E

kvm tools: Modify thread pool API

Modify API function names and type names.

[ penberg@kernel.org: drop virtio net parts ]
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Introduce generic I/O thread pool

This patch adds a generic pool to create a common interface for working with
threads within the kvm tool. Main idea here is using this threadpool for all

kvm tools: Introduce generic I/O thread pool

This patch adds a generic pool to create a common interface for working with
threads within the kvm tool. Main idea here is using this threadpool for all
I/O threads instead of having every I/O module write it's own thread code. The
process of working with the thread pool is supposed to be very simple.

During initialization, each module which is interested in working with the
threadpool will call threadpool__add_jobtype with the callback function and a
void* parameter. For example, virtio modules will register every virt_queue as
a new job type. During operation, When theres work to do for a specific job,
the module will signal it to the queue and would expect the callback to be
called with proper parameters. It is assured that the callback will be called
once for every signal action and each callback will be called only once at a
time (i.e. callback functions themselves don't need to handle threading).

[ penberg@kernel.org: Use Lindent ]
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...