On Mon, Mar 17, 2014 at 01:53:57PM -0700, dbasehore . wrote:
> It will still be at least be pending after the specified time has
> passed. I'm proposing that we still set the timer. The difference is
> that there is a possibility the work will already be pending when the
> timer goes off. There
On Mon, Mar 17, 2014 at 7:40 AM, Tejun Heo wrote:
> Hello,
>
> On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote:
>> There's already behavior that is somewhat like that with the current
>> implementation. If there's an item on a workqueue, it could run at any
>> time. From the
Hello,
On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote:
> There's already behavior that is somewhat like that with the current
> implementation. If there's an item on a workqueue, it could run at any
> time. From the perspective of the driver/etc. that is using the
> workqueue, there
On Sat 15-03-14 13:22:53, dbasehore . wrote:
> Resurrecting this for further discussion about the root of the problem.
>
> mod_delayed_work_if_later addresses the problem one way, but the
> problem is still there for mod_delayed_work.
But flusher works care about only that one way, don't they?
On Sat 15-03-14 13:22:53, dbasehore . wrote:
Resurrecting this for further discussion about the root of the problem.
mod_delayed_work_if_later addresses the problem one way, but the
problem is still there for mod_delayed_work.
But flusher works care about only that one way, don't they? We
Hello,
On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote:
There's already behavior that is somewhat like that with the current
implementation. If there's an item on a workqueue, it could run at any
time. From the perspective of the driver/etc. that is using the
workqueue, there
On Mon, Mar 17, 2014 at 7:40 AM, Tejun Heo t...@kernel.org wrote:
Hello,
On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote:
There's already behavior that is somewhat like that with the current
implementation. If there's an item on a workqueue, it could run at any
time. From the
On Mon, Mar 17, 2014 at 01:53:57PM -0700, dbasehore . wrote:
It will still be at least be pending after the specified time has
passed. I'm proposing that we still set the timer. The difference is
that there is a possibility the work will already be pending when the
timer goes off. There will
Also, the difference it would make is fix the issue for when a
delayed_work is used for both immediate work (mod_delayed_work(0)) and
delayed work.
On Sun, Mar 16, 2014 at 12:13 PM, dbasehore . wrote:
> There's already behavior that is somewhat like that with the current
> implementation. If
There's already behavior that is somewhat like that with the current
implementation. If there's an item on a workqueue, it could run at any
time. From the perspective of the driver/etc. that is using the
workqueue, there should be no difference between work being on the
workqueue and the kernel
On Sat, Mar 15, 2014 at 01:22:53PM -0700, dbasehore . wrote:
> mod_delayed_work currently removes a work item from a workqueue if it
> is on it. Correct me if I'm wrong, but I don't think that this is
> necessarily required for mod_delayed_work to have the current
> behavior. We should be able to
On Sat, Mar 15, 2014 at 01:22:53PM -0700, dbasehore . wrote:
mod_delayed_work currently removes a work item from a workqueue if it
is on it. Correct me if I'm wrong, but I don't think that this is
necessarily required for mod_delayed_work to have the current
behavior. We should be able to set
There's already behavior that is somewhat like that with the current
implementation. If there's an item on a workqueue, it could run at any
time. From the perspective of the driver/etc. that is using the
workqueue, there should be no difference between work being on the
workqueue and the kernel
Also, the difference it would make is fix the issue for when a
delayed_work is used for both immediate work (mod_delayed_work(0)) and
delayed work.
On Sun, Mar 16, 2014 at 12:13 PM, dbasehore . dbaseh...@chromium.org wrote:
There's already behavior that is somewhat like that with the current
Resurrecting this for further discussion about the root of the problem.
mod_delayed_work_if_later addresses the problem one way, but the
problem is still there for mod_delayed_work. I think we could take
another approach that doesn't modify the API, but still addresses
(most of) the problem.
Resurrecting this for further discussion about the root of the problem.
mod_delayed_work_if_later addresses the problem one way, but the
problem is still there for mod_delayed_work. I think we could take
another approach that doesn't modify the API, but still addresses
(most of) the problem.
On Tue 11-03-14 11:23:55, Andrew Morton wrote:
> On Wed, 19 Feb 2014 14:01:39 -0500 Tejun Heo wrote:
>
> > Hello, Jan.
> >
> > On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
> > > You are the workqueue expert so you may know better ;) But the way I
> > > understand it is that
On Wed, 19 Feb 2014 14:01:39 -0500 Tejun Heo wrote:
> Hello, Jan.
>
> On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
> > You are the workqueue expert so you may know better ;) But the way I
> > understand it is that queue_delayed_work() does nothing if the timer is
> > already
On Wed, 19 Feb 2014 14:01:39 -0500 Tejun Heo t...@kernel.org wrote:
Hello, Jan.
On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
You are the workqueue expert so you may know better ;) But the way I
understand it is that queue_delayed_work() does nothing if the timer is
On Tue 11-03-14 11:23:55, Andrew Morton wrote:
On Wed, 19 Feb 2014 14:01:39 -0500 Tejun Heo t...@kernel.org wrote:
Hello, Jan.
On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
You are the workqueue expert so you may know better ;) But the way I
understand it is that
Hello, Jan.
On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
> You are the workqueue expert so you may know better ;) But the way I
> understand it is that queue_delayed_work() does nothing if the timer is
> already running. Since we queue flusher work to run either immediately or
>
On Tue 18-02-14 17:55:48, Tejun Heo wrote:
> Hello,
>
> On Fri, Feb 14, 2014 at 08:12:17PM -0800, Derek Basehore wrote:
> > bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule
> > work
> > to writeback dirty inodes. The problem with this is that it can delay work
> > that
>
On Tue 18-02-14 17:55:48, Tejun Heo wrote:
Hello,
On Fri, Feb 14, 2014 at 08:12:17PM -0800, Derek Basehore wrote:
bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule
work
to writeback dirty inodes. The problem with this is that it can delay work
that
is
Hello, Jan.
On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
You are the workqueue expert so you may know better ;) But the way I
understand it is that queue_delayed_work() does nothing if the timer is
already running. Since we queue flusher work to run either immediately or
after
Hello,
On Fri, Feb 14, 2014 at 08:12:17PM -0800, Derek Basehore wrote:
> bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
> to writeback dirty inodes. The problem with this is that it can delay work
> that
> is scheduled for immediate execution, such as the work from
Hello,
On Fri, Feb 14, 2014 at 08:12:17PM -0800, Derek Basehore wrote:
bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
to writeback dirty inodes. The problem with this is that it can delay work
that
is scheduled for immediate execution, such as the work from
On Fri 14-02-14 20:12:17, Derek Basehore wrote:
> bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
> to writeback dirty inodes. The problem with this is that it can delay work
> that
> is scheduled for immediate execution, such as the work from sync_inodes_sb.
> This
On Fri 14-02-14 20:12:17, Derek Basehore wrote:
bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
to writeback dirty inodes. The problem with this is that it can delay work
that
is scheduled for immediate execution, such as the work from sync_inodes_sb.
This can
bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
to writeback dirty inodes. The problem with this is that it can delay work that
is scheduled for immediate execution, such as the work from sync_inodes_sb.
This can happen since mod_delayed_work can now steal work from a
bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
to writeback dirty inodes. The problem with this is that it can delay work that
is scheduled for immediate execution, such as the work from sync_inodes_sb.
This can happen since mod_delayed_work can now steal work from a
30 matches
Mail list logo
