Hello,
On Wed, Oct 14, 2015 at 12:20:22PM +0200, Petr Mladek wrote:
> IMHO, it would be great if it is easy to convert between the
> kthread worker and workqueues API. It will allow to choose
Sure, keep the APIs similar so that they can be easily converted back
and forth but that doesn't mean kth
On Wed 2015-10-07 07:24:46, Tejun Heo wrote:
> At each turn, you come up with non-issues and declare that it needs to
> be full workqueue-like implementation but the issues you're raising
> seem all rather irrelevant. Can you please try to take a step back
> and put some distance from the impleme
Hello, Petr.
On Wed, Oct 07, 2015 at 11:21:30AM +0200, Petr Mladek wrote:
> Now, let's have one work: W, two workers: A, B, and try to queue
> the same work to the two workers at the same time:
It's a debug WARN condition to catch silly mistakes. It can have
minor race conditions.
...
> Second,
On Mon 2015-10-05 13:09:24, Petr Mladek wrote:
> On Mon 2015-10-05 12:07:58, Petr Mladek wrote:
> > On Fri 2015-10-02 15:24:53, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Fri, Oct 02, 2015 at 05:43:36PM +0200, Petr Mladek wrote:
> > > > IMHO, we need both locks. The worker manipulates more works
On Mon 2015-10-05 12:07:58, Petr Mladek wrote:
> On Fri 2015-10-02 15:24:53, Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Oct 02, 2015 at 05:43:36PM +0200, Petr Mladek wrote:
> > > IMHO, we need both locks. The worker manipulates more works and
> > > need its own lock. We need work-specific lock be
On Fri 2015-10-02 15:24:53, Tejun Heo wrote:
> Hello,
>
> On Fri, Oct 02, 2015 at 05:43:36PM +0200, Petr Mladek wrote:
> > IMHO, we need both locks. The worker manipulates more works and
> > need its own lock. We need work-specific lock because the work
> > might be assigned to different workers a
Hello,
On Fri, Oct 02, 2015 at 05:43:36PM +0200, Petr Mladek wrote:
> IMHO, we need both locks. The worker manipulates more works and
> need its own lock. We need work-specific lock because the work
> might be assigned to different workers and we need to be sure
> that the operations are really se
On Mon 2015-09-28 13:03:14, Tejun Heo wrote:
> Hello, Petr.
>
> On Fri, Sep 25, 2015 at 01:26:17PM +0200, Petr Mladek wrote:
> > 1) PENDING state plus -EAGAIN/busy loop cycle
> > -
> >
> > IMHO, we want to use the timer because it is an elegant solution
Hello, Petr.
On Fri, Sep 25, 2015 at 01:26:17PM +0200, Petr Mladek wrote:
> 1) PENDING state plus -EAGAIN/busy loop cycle
> -
>
> IMHO, we want to use the timer because it is an elegant solution.
> Then we must release the lock when the timer is running
On Tue 2015-09-22 15:35:13, Tejun Heo wrote:
> On Mon, Sep 21, 2015 at 03:03:48PM +0200, Petr Mladek wrote:
> > /**
> > + * try_to_grab_pending_kthread_work - steal kthread work item from
> > worklist,
> > + * and disable irq
> > + * @work: work item to steal
> > + * @is_dwork: @work is a delayed
On Mon, Sep 21, 2015 at 03:03:48PM +0200, Petr Mladek wrote:
> /**
> + * try_to_grab_pending_kthread_work - steal kthread work item from worklist,
> + * and disable irq
> + * @work: work item to steal
> + * @is_dwork: @work is a delayed_work
> + * @flags: place to store irq state
> + *
> + * Try
11 matches
Mail list logo
