search for: kthread_work

Currently, it's only possible to flush on a kthread_work in contexts where it's possible to block. This can be kind of painful though when trying to implement new types of delayed work which use kthread_work, since it means we'd need to drop any spinlocks for new delayed work implementations before we can actually call kthread_flush_work(). In t...

Add some simple wrappers around incrementing/decrementing kthread_work.cancelling under lock, along with checking whether queuing is currently allowed on a given kthread_work, which we'll use want to implement work cancelling with DRM's vblank work helpers. Cc: Daniel Vetter <daniel at ffwll.ch> Cc: Tejun Heo <tj at kernel.org> Cc: Ville Syrj?l? &...

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

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up with: vblank workers. Basically, this is just a generic DRM interface that allows for scheduling high-priority workers that start on a given vblank interrupt. Note that while we're currently only using this...

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

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled - whichever comes f...

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled - whichever comes f...

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 is asking them to queu...

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled - whichever comes f...

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

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

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up with: vblank workers. Basically, this is just a generic DRM interface that allows for scheduling high-priority workers that start on a given vblank interrupt. Note that while we're currently only using this...

...et); - break; - case CRYPTO_ALG_TYPE_ABLKCIPHER: - breq = ablkcipher_request_cast(engine->cur_req); - crypto_finalize_cipher_request(engine, breq, ret); - break; - } + crypto_finalize_request(engine, async_req, ret); return; out: @@ -170,59 +142,16 @@ static void crypto_pump_work(struct kthread_work *work) } /** - * crypto_transfer_cipher_request - transfer the new request into the - * enginequeue + * crypto_transfer_request - transfer the new request into the engine queue * @engine: the hardware engine * @req: the request need to be listed into the engine queue */ -int crypto_transf...

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

...: > - breq = ablkcipher_request_cast(engine->cur_req); > - crypto_finalize_cipher_request(engine, breq, ret); > - break; > - } > + crypto_finalize_request(engine, async_req, ret); > return; > > out: > @@ -170,13 +141,12 @@ static void crypto_pump_work(struct kthread_work *work) > } > > /** > - * crypto_transfer_cipher_request - transfer the new request into the > - * enginequeue > + * crypto_transfer_request - transfer the new request into the engine queue > * @engine: the hardware engine > * @req: the request need to be listed...