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