History log of /kvmtool/util/threadpool.c (Results 1 – 13 of 13)
Revision Date Author Comments
# 7a7f4542 10-Jan-2019 Jean-Philippe Brucker <jean-philippe.brucker@arm.com>

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 ...


# d3476f7d 24-Oct-2012 Sasha Levin <sasha.levin@oracle.com>

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 ...


# a4d8c55e 24-Oct-2012 Sasha Levin <sasha.levin@oracle.com>

kvm tools: Specify names for VM internal threads

Give threads a meaningful name. This makes debugging much easier, and
everything else much prettier.

Suggested-by: Ingo Molnar <mingo@kernel.org>
Si

kvm tools: Specify names for VM internal threads

Give threads a meaningful name. This makes debugging much easier, and
everything else much prettier.

Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
[ penberg@kernel.org: specify vcpu names ]
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...


# 49a8afd1 17-Sep-2012 Sasha Levin <levinsasha928@gmail.com>

kvm tools: use init/exit where possible

Switch to using init/exit calls instead of the repeating call blocks in builtin-run.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekk

kvm tools: use init/exit where possible

Switch to using init/exit calls instead of the repeating call blocks in builtin-run.

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

show more ...


# feceecd7 17-Sep-2012 Sasha Levin <levinsasha928@gmail.com>

kvm tools: initialize the threadpool job iterator before using

This would fix a bug where the exit function of the threadpool would hang
if no jobs were processed yet and a request to exit was recei

kvm tools: initialize the threadpool job iterator before using

This would fix a bug where the exit function of the threadpool would hang
if no jobs were processed yet and a request to exit was received.

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

show more ...


# f6a3c571 05-Sep-2012 Sasha Levin <levinsasha928@gmail.com>

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 ...


# 42fe1e6b 12-Dec-2011 Lai Jiangshan <laijs@cn.fujitsu.com>

kvm tools: move threadpool.c to util/

threadpool.c contains no kvm related code, it is just a lib.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Pekka Enberg <penberg@kernel.or

kvm tools: move threadpool.c to util/

threadpool.c contains no kvm related code, it is just a lib.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...


# a4cae5ab 12-Dec-2011 Lai Jiangshan <laijs@cn.fujitsu.com>

kvm tools: fix function name

In here, xxx_locked() should means "called with job_mutex locked",
the original funtion are opposite, fix them.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Sign

kvm tools: fix function name

In here, xxx_locked() should means "called with job_mutex locked",
the original funtion are opposite, fix them.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...


# c57cd4b7 12-Dec-2011 Lai Jiangshan <laijs@cn.fujitsu.com>

kvm tools: check condition before wait

We should check the condition before wait it,
otherewise we may get deadlock.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Pekka Enberg

kvm tools: check condition before wait

We should check the condition before wait it,
otherewise we may get deadlock.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...


# df0c7f57 02-Jul-2011 Sasha Levin <levinsasha928@gmail.com>

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 ...


# 9449cd3c 30-Apr-2011 Sasha Levin <levinsasha928@gmail.com>

kvm tools: Lock job_mutex before signalling

Locking mutex before signalling to prevent unexpected
scheduling.

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

kvm tools: Lock job_mutex before signalling

Locking mutex before signalling to prevent unexpected
scheduling.

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

show more ...


# f6a083e9 29-Apr-2011 Sasha Levin <levinsasha928@gmail.com>

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 ...


# d60bafe5 28-Apr-2011 Sasha Levin <levinsasha928@gmail.com>

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 ...