search for: kthread_worker

...r own contexts so that we can block until a vblank work's target vblank has passed, _and_ said work has executed once since. And finally, we also want to be able to finish flushing on a work early if it's been cancelled at any point (e.g. before or after it's actually been queued on the kthread_worker). So, let's make all of these things possible by exposing struct kthread_flush_work, and then splitting kthread_flush_work() into two functions: kthread_queue_flush_work(); which handles possibly queuing up the kthread_flush_work on the work's respective kthread_worker, and kthread_flush_w...

...| 46 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+) diff --git a/include/linux/kthread.h b/include/linux/kthread.h index 0006540ce7f9..c6fee200fced 100644 --- a/include/linux/kthread.h +++ b/include/linux/kthread.h @@ -211,9 +211,28 @@ void kthread_flush_worker(struct kthread_worker *worker); bool kthread_cancel_work_sync(struct kthread_work *work); bool kthread_cancel_delayed_work_sync(struct kthread_delayed_work *work); +void kthread_block_work_queuing(struct kthread_worker *worker, + struct kthread_work *work); +void kthread_unblock_work_queuing(struct kthread_worker...

...it a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h > index 4774292fba8c..3a42887d05d9 100644 > --- a/drivers/vdpa/vdpa_sim/vdpa_sim.h > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h > @@ -59,6 +59,7 @@ struct vdpasim { > struct vdpasim_virtqueue *vqs; > struct kthread_worker *worker; > struct kthread_work work; > + struct mm_struct *mm_bound; > struct vdpasim_dev_attr dev_attr; > /* mutex to synchronize virtqueue state */ > struct mutex mutex; > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c > index ab4...

...rity workers that start on a given vblank interrupt. Note that while we're currently only using this in nouveau, Intel has plans to use this for i915 as well (hence why they came up with it!). And finally: in order to implement the last feature, we expose some new functions in the kernel's kthread_worker infrastructure so that we can de-complicate our implementation of this. Anyway-welcome to the future! :) Major changes since v3: * Style fixes on nouveau patches from checkpatch, no functional changes * Don't integrate so tightly with kthread_work (and use our own lock), instead introduce s...

...rs/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h > index 4774292fba8c..3a42887d05d9 100644 > --- a/drivers/vdpa/vdpa_sim/vdpa_sim.h > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h > @@ -59,6 +59,7 @@ struct vdpasim { > struct vdpasim_virtqueue *vqs; > struct kthread_worker *worker; > struct kthread_work work; > + struct mm_struct *mm_bound; > struct vdpasim_dev_attr dev_attr; > /* mutex to synchronize virtqueue state */ > struct mutex mutex; > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim...

...the kernel, it seems a bit unnecessary anyway. * Get rid of to_drm_vblank_work() since we now are also able to just pass the struct drm_vblank_work to work item callbacks anyway Changes since v3: * Use our own spinlocks, don't integrate so tightly with kthread_works Changes since v2: * Use kthread_workers instead of reinventing the wheel. Cc: Daniel Vetter <daniel at ffwll.ch> Cc: Tejun Heo <tj at kernel.org> Cc: Ville Syrj?l? <ville.syrjala at linux.intel.com> Cc: dri-devel at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Signed-off-by: Lyude Paul <lyude at redha...

...). As such we use a high-priority per-CRTC thread to accomplish this. [based off patches from Ville Syrj?l? <ville.syrjala at linux.intel.com>, change below to signoff later] Changes since v3: * Use our own spinlocks, don't integrate so tightly with kthread_works Changes since v2: * Use kthread_workers instead of reinventing the wheel. Cc: Daniel Vetter <daniel at ffwll.ch> Cc: Tejun Heo <tj at kernel.org> Cc: Ville Syrj?l? <ville.syrjala at linux.intel.com> Cc: dri-devel at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Signed-off-by: Lyude Paul <lyude at redha...

Let's move work management inside the vdpa_sim core. This way we can easily change how we manage the works, without having to change the devices each time. Acked-by: Eugenio P??rez Martin <eperezma at redhat.com> Acked-by: Jason Wang <jasowang at redhat.com> Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- drivers/vdpa/vdpa_sim/vdpa_sim.h | 3 ++-

Hello, On Mon, Apr 13, 2020 at 04:18:57PM -0400, Lyude Paul wrote: > Hi Tejun! Sorry to bother you, but have you had a chance to look at any of > this yet? Would like to continue moving this forward Sorry, wasn't following this thread. Have you looked at kthread_worker? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kthread.h#n71 And, thanks a lot for the vblank explanation. I really enjoyed readin it. :) -- tejun

Hello, On Fri, May 08, 2020 at 04:46:51PM -0400, Lyude Paul wrote: > +bool kthread_queue_flush_work(struct kthread_work *work, > + struct kthread_flush_work *fwork); > +void __kthread_flush_work_fn(struct kthread_work *work); As an exposed interface, this doesn't seem great. What the user wants to say is "wait for the current instance of this guy" and the interface

...the kernel, it seems a bit unnecessary anyway. * Get rid of to_drm_vblank_work() since we now are also able to just pass the struct drm_vblank_work to work item callbacks anyway Changes since v3: * Use our own spinlocks, don't integrate so tightly with kthread_works Changes since v2: * Use kthread_workers instead of reinventing the wheel. Cc: Daniel Vetter <daniel at ffwll.ch> Cc: Tejun Heo <tj at kernel.org> Cc: dri-devel at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Co-developed-by: Ville Syrj?l? <ville.syrjala at linux.intel.com> Signed-off-by: Lyude Paul <l...

...rs/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h > index 4774292fba8c..3a42887d05d9 100644 > --- a/drivers/vdpa/vdpa_sim/vdpa_sim.h > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h > @@ -59,6 +59,7 @@ struct vdpasim { > struct vdpasim_virtqueue *vqs; > struct kthread_worker *worker; > struct kthread_work work; > + struct mm_struct *mm_bound; > struct vdpasim_dev_attr dev_attr; > /* mutex to synchronize virtqueue state */ > struct mutex mutex; > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim...

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the

v2: - rebased on Linus' tree, commit ae3419fbac84 ("vc_screen: don't clobber return value in vcs_read") - removed `struct task_struct *owner` param (unused for now, maybe ?useful to support cgroups) [Jason] - add unbind_mm callback [Jason] - call the new unbind_mm callback during the release [Jason] - avoid to call bind_mm callback after the reset, since the device ?is not

...+-- 4 files changed, 23 insertions(+), 23 deletions(-) diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.h b/drivers/vdpa/vdpa_sim/vdpa_sim.h index ce83f9130a5d..4774292fba8c 100644 --- a/drivers/vdpa/vdpa_sim/vdpa_sim.h +++ b/drivers/vdpa/vdpa_sim/vdpa_sim.h @@ -60,8 +60,8 @@ struct vdpasim { struct kthread_worker *worker; struct kthread_work work; struct vdpasim_dev_attr dev_attr; - /* spinlock to synchronize virtqueue state */ - spinlock_t lock; + /* mutex to synchronize virtqueue state */ + struct mutex mutex; /* virtio config according to device type */ void *config; struct vhost_iotlb *iommu;...

...t; Hello, > > On Mon, Apr 13, 2020 at 04:18:57PM -0400, Lyude Paul wrote: > > Hi Tejun! Sorry to bother you, but have you had a chance to look at any of > > this yet? Would like to continue moving this forward > > Sorry, wasn't following this thread. Have you looked at kthread_worker? > Hi, thanks for the response! And yes-I think this would actually be perfect for what we need, I guess one question I might as well ask since I've got you here: would patches to expose an unlocked version of kthread_queue_worker() be accepted? With something like that I should be able to...

...rity workers that start on a given vblank interrupt. Note that while we're currently only using this in nouveau, Intel has plans to use this for i915 as well (hence why they came up with it!). And finally: in order to implement the last feature, we expose some new functions in the kernel's kthread_worker infrastructure so that we can de-complicate our implementation of this. Anyway-welcome to the future! :) Major changes since v6: * Move vblank_work related functions into their own files * Write documentation * Simplify work flushing and cancellation by getting rid of seqcounts and ->pending...

...- int (*unprepare_hash_request)(struct crypto_engine *engine, - struct ahash_request *req); - int (*cipher_one_request)(struct crypto_engine *engine, - struct ablkcipher_request *req); - int (*hash_one_request)(struct crypto_engine *engine, - struct ahash_request *req); - struct kthread_worker *kworker; struct kthread_work pump_requests; @@ -85,19 +71,25 @@ struct crypto_engine { struct crypto_async_request *cur_req; }; -int crypto_transfer_cipher_request(struct crypto_engine *engine, - struct ablkcipher_request *req, - bool need_pump); -int cry...

...on a given vblank interrupt. > Note that while we're currently only using this in nouveau, Intel has > plans to use this for i915 as well (hence why they came up with it!). > > And finally: in order to implement the last feature, we expose some new > functions in the kernel's kthread_worker infrastructure so that we can > de-complicate our implementation of this. > > Anyway-welcome to the future! :) The Nouveau bits look alright to me, I'll take them once the patches it depends on have been acked. Ben. > > Major changes since v2: > * Use kthread_worker instead...

...uct crypto_engine *engine, > - struct ahash_request *req); > - int (*cipher_one_request)(struct crypto_engine *engine, > - struct ablkcipher_request *req); > - int (*hash_one_request)(struct crypto_engine *engine, > - struct ahash_request *req); > - > struct kthread_worker *kworker; > struct kthread_work pump_requests; > > @@ -85,19 +68,43 @@ struct crypto_engine { > struct crypto_async_request *cur_req; > }; > > -int crypto_transfer_cipher_request(struct crypto_engine *engine, > - struct ablkcipher_re...