search for: delayed_work

...with a > > >> DPU-powered virtio-fs device. > > >> > > >> Signed-off-by: Peter-Jan Gootzen <peter-jan at gootzen.net> > > >> --- > > >> V1 -> V2: Not scheduling dispatch work anymore when not needed > > >> and changed delayed_work structs to work_struct structs > > >> > > >> fs/fuse/virtio_fs.c | 32 +++++++++++++++++--------------- > > >> 1 file changed, 17 insertions(+), 15 deletions(-) > > >> > > >> diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c > &gt...

...size of the Virtio queue size, with a > >> DPU-powered virtio-fs device. > >> > >> Signed-off-by: Peter-Jan Gootzen <peter-jan at gootzen.net> > >> --- > >> V1 -> V2: Not scheduling dispatch work anymore when not needed > >> and changed delayed_work structs to work_struct structs > >> > >> fs/fuse/virtio_fs.c | 32 +++++++++++++++++--------------- > >> 1 file changed, 17 insertions(+), 15 deletions(-) > >> > >> diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c > >> index 4d8d4f16c727....

...tch. V3: Fixed requests falling into the void when -ENOMEM and no new incoming requests. Virtio-fs now always lets -ENOMEM bubble up to userspace. Also made queue full condition more explicit with -ENOSPC in `send_forget_request`. V2: Not scheduling dispatch work anymore when not needed and changed delayed_work structs to work_struct structs fs/fuse/virtio_fs.c | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index 4d8d4f16c727..a676297db09b 100644 --- a/fs/fuse/virtio_fs.c +++ b/fs/fuse/virtio_fs.c @@ -45,7...

...19 +137,10 @@ struct virtio_gpu_framebuffer { #define to_virtio_gpu_framebuffer(x) \ container_of(x, struct virtio_gpu_framebuffer, base) -struct virtio_gpu_fbdev { - struct drm_fb_helper helper; - struct virtio_gpu_framebuffer vgfb; - struct virtio_gpu_device *vgdev; - struct delayed_work work; -}; - struct virtio_gpu_mman { struct ttm_bo_device bdev; }; -struct virtio_gpu_fbdev; - struct virtio_gpu_queue { struct virtqueue *vq; spinlock_t qlock; @@ -180,8 +171,6 @@ struct virtio_gpu_device { struct virtio_gpu_mman mman; - /* pointer to fbdev info struct...

...60x and slightly increases the overall throughput, when using a queue depth 2x the size of the Virtio queue size, with a DPU-powered virtio-fs device. Signed-off-by: Peter-Jan Gootzen <peter-jan at gootzen.net> --- V1 -> V2: Not scheduling dispatch work anymore when not needed and changed delayed_work structs to work_struct structs fs/fuse/virtio_fs.c | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index 4d8d4f16c727..a676297db09b 100644 --- a/fs/fuse/virtio_fs.c +++ b/fs/fuse/virtio_fs.c @@ -45,7...

...>>>> DPU-powered virtio-fs device. >>>>> >>>>> Signed-off-by: Peter-Jan Gootzen <peter-jan at gootzen.net> >>>>> --- >>>>> V1 -> V2: Not scheduling dispatch work anymore when not needed >>>>> and changed delayed_work structs to work_struct structs >>>>> >>>>> fs/fuse/virtio_fs.c | 32 +++++++++++++++++--------------- >>>>> 1 file changed, 17 insertions(+), 15 deletions(-) >>>>> >>>>> diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs....

...d go > if (vb->oom) > msleep(1000); > at beginning of fill_balloon. I don't think it is a good manner to sleep for long from the point of view of system_freezable_wq, for system_freezable_wq is expected to flush shortly according to include/linux/workqueue.h . I think that using delayed_work is better. > > While response was better than now, inflating again spoiled the effort. > > Retrying to inflate until allocation fails is already too painful. > > > > Michael S. Tsirkin wrote: > > > I think that's the case. Question is, when can we inflate agai...

...d go > if (vb->oom) > msleep(1000); > at beginning of fill_balloon. I don't think it is a good manner to sleep for long from the point of view of system_freezable_wq, for system_freezable_wq is expected to flush shortly according to include/linux/workqueue.h . I think that using delayed_work is better. > > While response was better than now, inflating again spoiled the effort. > > Retrying to inflate until allocation fails is already too painful. > > > > Michael S. Tsirkin wrote: > > > I think that's the case. Question is, when can we inflate agai...

...btrfs_set_max_workers(&fs_info->endio_write_workers, new_pool_size); - btrfs_set_max_workers(&fs_info->endio_freespace_worker, new_pool_size); + btrfs_set_max_workers(&fs_info->endio_freespace_worker, + min(1, new_pool_size)); btrfs_set_max_workers(&fs_info->delayed_workers, new_pool_size); btrfs_set_max_workers(&fs_info->readahead_workers, new_pool_size); btrfs_set_max_workers(&fs_info->scrub_workers, new_pool_size); -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...

...erged, as the code in ramster that provoked it is directly leveraged from ocfs2 o2net. > From: Tejun Heo [mailto:tj at kernel.org] > Sent: Thursday, October 18, 2012 5:39 PM > To: Dan Magenheimer > Cc: linux-kernel at vger.kernel.org; Konrad Wilk > Subject: [PATCH] workqueue: cancel_delayed_work() should return %NULL if work item is idle > > From e65120fcfc1cb9697655d29ecd7982451c05d3c2 Mon Sep 17 00:00:00 2001 > From: Dan Magenheimer <dan.magenheimer at oracle.com> > Date: Thu, 18 Oct 2012 16:31:37 -0700 > > 57b30ae77b ("workqueue: reimplement cancel_delayed...

...probe_helper.c > b/drivers/gpu/drm/drm_probe_helper.c > index 555fbe54d6e2..019881d15ce1 100644 > --- a/drivers/gpu/drm/drm_probe_helper.c > +++ b/drivers/gpu/drm/drm_probe_helper.c > @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct > *work) > schedule_delayed_work(delayed_work, > DRM_OUTPUT_POLL_PERIOD); > } > > +/** > + * drm_kms_helper_is_poll_worker - is %current task an output poll worker? > + * > + * Determine if %current task is an output poll worker. This can be used > + * to select distinct code paths for output polling ve...

...x/mutex.h> #include <linux/virtio.h> #include <linux/virtio_net.h> #include <linux/scatterlist.h> @@ -68,15 +69,21 @@ struct virtnet_info { /* Active statistics */ struct virtnet_stats __percpu *stats; - /* Work struct for refilling if we run low on memory. */ - struct delayed_work refill; - /* Chain pages by the private ptr. */ struct page *pages; /* fragments + linear part + virtio header */ struct scatterlist rx_sg[MAX_SKB_FRAGS + 2]; struct scatterlist tx_sg[MAX_SKB_FRAGS + 2]; + + /* Work struct for refilling if we run low on memory. */ + struct delayed_work...

...x/mutex.h> #include <linux/virtio.h> #include <linux/virtio_net.h> #include <linux/scatterlist.h> @@ -68,15 +69,21 @@ struct virtnet_info { /* Active statistics */ struct virtnet_stats __percpu *stats; - /* Work struct for refilling if we run low on memory. */ - struct delayed_work refill; - /* Chain pages by the private ptr. */ struct page *pages; /* fragments + linear part + virtio header */ struct scatterlist rx_sg[MAX_SKB_FRAGS + 2]; struct scatterlist tx_sg[MAX_SKB_FRAGS + 2]; + + /* Work struct for refilling if we run low on memory. */ + struct delayed_work...

Fix theoretical races related to refill work: 1. After napi is disabled by ndo_stop, refill work can run and re-enable it. 2. Refill can reschedule itself, if this happens it can run after cancel_delayed_work_sync, and will access device after it is destroyed. As a solution, add flags to track napi state and to disable refill, and toggle them on start, stop and remove; check these flags on refill. refill work structure and new fields aren't used on data path, so put them together near the end o...

Fix theoretical races related to refill work: 1. After napi is disabled by ndo_stop, refill work can run and re-enable it. 2. Refill can reschedule itself, if this happens it can run after cancel_delayed_work_sync, and will access device after it is destroyed. As a solution, add flags to track napi state and to disable refill, and toggle them on start, stop and remove; check these flags on refill. refill work structure and new fields aren't used on data path, so put them together near the end o...

...le as a fallback in case of not working interrupts as well as a chance for any driver to do necessary lockup handling. Christian. > I guess for radeon we just have to add tons of insulation by punting > all callbacks to work items so that radeon can do whatever it wants. > Plus start a delayed_work based fallback when ->enable_signalling is > called to make sure we work on platforms that lack interrupts. > -Daniel

...ueue *rvq, *svq, *cvq; @@ -56,6 +65,9 @@ struct virtnet_info { /* Host will merge rx buffers for big packets (shake it! shake it!) */ bool mergeable_rx_bufs; + /* Active statistics */ + struct virtnet_stats __percpu *stats; + /* Work struct for refilling if we run low on memory. */ struct delayed_work refill; @@ -209,7 +221,6 @@ static int receive_mergeable(struct virt skb->dev->stats.rx_length_errors++; return -EINVAL; } - page = virtqueue_get_buf(vi->rvq, &len); if (!page) { pr_debug("%s: rx error: %d buffers missing\n", @@ -217,6 +228,7 @@ static...

...ueue *rvq, *svq, *cvq; @@ -56,6 +65,9 @@ struct virtnet_info { /* Host will merge rx buffers for big packets (shake it! shake it!) */ bool mergeable_rx_bufs; + /* Active statistics */ + struct virtnet_stats __percpu *stats; + /* Work struct for refilling if we run low on memory. */ struct delayed_work refill; @@ -209,7 +221,6 @@ static int receive_mergeable(struct virt skb->dev->stats.rx_length_errors++; return -EINVAL; } - page = virtqueue_get_buf(vi->rvq, &len); if (!page) { pr_debug("%s: rx error: %d buffers missing\n", @@ -217,6 +228,7 @@ static...

...diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c index 6dc2dde5b672..7a6b2dc08913 100644 --- a/drivers/gpu/drm/drm_probe_helper.c +++ b/drivers/gpu/drm/drm_probe_helper.c @@ -654,6 +654,26 @@ static void output_poll_execute(struct work_struct *work) schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD); } +/** + * drm_kms_helper_is_poll_worker - is %current task an output poll worker? + * + * Determine if %current task is an output poll worker. This can be used + * to select distinct code paths for output polling versus other contexts. + * + * One use cas...

Am 23.07.2014 11:55, schrieb Maarten Lankhorst: > op 23-07-14 11:47, Christian K?nig schreef: >> Am 23.07.2014 11:44, schrieb Daniel Vetter: >>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: >>>> The scheduler needs to keep track of a lot of fences, so I think we'll >>>> have to register callbacks, not a