Hello, Peter.
On Wed, Aug 15, 2012 at 12:58:27PM +0200, Peter Zijlstra wrote:
> On Tue, 2012-08-14 at 17:18 -0700, Tejun Heo wrote:
> > Let's see if we can agree on the latter point first. Do you agree
> > that it wouldn't be a good idea to implement relatively complex timer
> > subsystem inside
Hello, Peter.
On Wed, Aug 15, 2012 at 12:58:27PM +0200, Peter Zijlstra wrote:
On Tue, 2012-08-14 at 17:18 -0700, Tejun Heo wrote:
Let's see if we can agree on the latter point first. Do you agree
that it wouldn't be a good idea to implement relatively complex timer
subsystem inside
On Tue, 2012-08-14 at 17:18 -0700, Tejun Heo wrote:
> Let's see if we can agree on the latter point first. Do you agree
> that it wouldn't be a good idea to implement relatively complex timer
> subsystem inside workqueue?
RB-trees are fairly trivial to use, but can we please get back to why
On Tue, 2012-08-14 at 17:18 -0700, Tejun Heo wrote:
Let's see if we can agree on the latter point first. Do you agree
that it wouldn't be a good idea to implement relatively complex timer
subsystem inside workqueue?
RB-trees are fairly trivial to use, but can we please get back to why
people
Hello, Thomas.
On Wed, Aug 15, 2012 at 01:33:09AM +0200, Thomas Gleixner wrote:
> To convince me to accept your patches you should start answering my
> questions and suggestions seriously in the first place and not
> discarding them upfront as lunatic visions.
>
> As long as you can't provide a
Hello,
On Tue, Aug 14, 2012 at 4:46 PM, Thomas Gleixner wrote:
> Do you really expect that I follow all of kernel dev posts within a
> day of returning from a two weeks vacation?
The head message says on what it's based on and the git branch. I
can't read your mind or know your current state.
Tejun,
On Tue, 14 Aug 2012, Tejun Heo wrote:
> On Wed, Aug 15, 2012 at 01:12:01AM +0200, Thomas Gleixner wrote:
> > Just for the record. The thread evolved from here:
> >
> > * mod_delayed_work() can't be used from IRQ handlers.
> >
> > My answer was:
> >
> > This function does not
On Tue, 14 Aug 2012, Tejun Heo wrote:
> On Wed, Aug 15, 2012 at 12:45:24AM +0200, Thomas Gleixner wrote:
> > And we have very well worked out mechanisms regarding cross tree
> > changes, i.e. providing minimal trees to pull for other maintainers.
>
> If you look at the review branches, they're
Hello, Thomas.
On Wed, Aug 15, 2012 at 01:12:01AM +0200, Thomas Gleixner wrote:
> Just for the record. The thread evolved from here:
>
> * mod_delayed_work() can't be used from IRQ handlers.
>
> My answer was:
>
> This function does not exist. So what?
>
> Which was completely
Tejun,
On Tue, 14 Aug 2012, Tejun Heo wrote:
> On Tue, Aug 14, 2012 at 10:43:30PM +0200, Thomas Gleixner wrote:
> > > It makes the workqueue users messy. It's difficult to get completely
> > > correct and subtle errors are difficult to detect / verify.
> >
> > Ah, the function which does not
Hello, Thomas.
On Wed, Aug 15, 2012 at 12:45:24AM +0200, Thomas Gleixner wrote:
> And we have very well worked out mechanisms regarding cross tree
> changes, i.e. providing minimal trees to pull for other maintainers.
If you look at the review branches, they're actually structured that
way so
Tejun,
On Tue, 14 Aug 2012, Tejun Heo wrote:
> On Tue, Aug 14, 2012 at 11:03:33PM +0200, Thomas Gleixner wrote:
> > Why should -next have different rules to mainline?
>
> It's faster paced and trees revert. The message specifically was a
Nonsense. It's a tree which gets stuff which is cooked
Hello, Thomas.
On Tue, Aug 14, 2012 at 11:03:33PM +0200, Thomas Gleixner wrote:
> Why should -next have different rules to mainline?
It's faster paced and trees revert. The message specifically was a
ping for objection and I was waiting for further response and would
have waited until early
Hello, Thomas.
On Tue, Aug 14, 2012 at 10:43:30PM +0200, Thomas Gleixner wrote:
> > It makes the workqueue users messy. It's difficult to get completely
> > correct and subtle errors are difficult to detect / verify.
>
> Ah, the function which does not exist makes the users
> messy. Interesting
On Tue, 14 Aug 2012, Tejun Heo wrote:
> On Tue, Aug 14, 2012 at 09:16:16PM +0200, Thomas Gleixner wrote:
> > Why the hell are you trying to rush stuff which affects a well
> > maintained part of the kernel through your own tree w/o having the
> > courtesy of contacting the maintainer politely
On Tue, 14 Aug 2012, Tejun Heo wrote:
> On Tue, Aug 14, 2012 at 08:55:16PM +0200, Thomas Gleixner wrote:
> > > * mod_delayed_work() can't be used from IRQ handlers.
> >
> > This function does not exist. So what?
>
> It makes the workqueue users messy. It's difficult to get completely
> correct
Hello,
On Tue, Aug 14, 2012 at 09:16:16PM +0200, Thomas Gleixner wrote:
> Why the hell are you trying to rush stuff which affects a well
> maintained part of the kernel through your own tree w/o having the
> courtesy of contacting the maintainer politely instead of sending an
> ultimatum?
>
> You
On Mon, 13 Aug 2012, Tejun Heo wrote:
> On Wed, Aug 08, 2012 at 11:10:24AM -0700, Tejun Heo wrote:
> > Timer internals are protected by irqsafe lock but the lock is
> > naturally dropped and irq enabled while a timer is executed. This
> > makes dequeueing timer for execution and the actual
Hello, Thomas.
On Tue, Aug 14, 2012 at 08:55:16PM +0200, Thomas Gleixner wrote:
> > * mod_delayed_work() can't be used from IRQ handlers.
>
> This function does not exist. So what?
It makes the workqueue users messy. It's difficult to get completely
correct and subtle errors are difficult to
On Wed, 8 Aug 2012, Tejun Heo wrote:
> Timer internals are protected by irqsafe lock but the lock is
> naturally dropped and irq enabled while a timer is executed. This
> makes dequeueing timer for execution and the actual execution
> non-atomic against IRQs. No matter what the timer function
On Mon, 13 Aug 2012, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 08, 2012 at 11:10:24AM -0700, Tejun Heo wrote:
> > Timer internals are protected by irqsafe lock but the lock is
> > naturally dropped and irq enabled while a timer is executed. This
> > makes dequeueing timer for execution and the
On Mon, 13 Aug 2012, Tejun Heo wrote:
Hello,
On Wed, Aug 08, 2012 at 11:10:24AM -0700, Tejun Heo wrote:
Timer internals are protected by irqsafe lock but the lock is
naturally dropped and irq enabled while a timer is executed. This
makes dequeueing timer for execution and the actual
On Wed, 8 Aug 2012, Tejun Heo wrote:
Timer internals are protected by irqsafe lock but the lock is
naturally dropped and irq enabled while a timer is executed. This
makes dequeueing timer for execution and the actual execution
non-atomic against IRQs. No matter what the timer function does,
Hello, Thomas.
On Tue, Aug 14, 2012 at 08:55:16PM +0200, Thomas Gleixner wrote:
* mod_delayed_work() can't be used from IRQ handlers.
This function does not exist. So what?
It makes the workqueue users messy. It's difficult to get completely
correct and subtle errors are difficult to
On Mon, 13 Aug 2012, Tejun Heo wrote:
On Wed, Aug 08, 2012 at 11:10:24AM -0700, Tejun Heo wrote:
Timer internals are protected by irqsafe lock but the lock is
naturally dropped and irq enabled while a timer is executed. This
makes dequeueing timer for execution and the actual execution
Hello,
On Tue, Aug 14, 2012 at 09:16:16PM +0200, Thomas Gleixner wrote:
Why the hell are you trying to rush stuff which affects a well
maintained part of the kernel through your own tree w/o having the
courtesy of contacting the maintainer politely instead of sending an
ultimatum?
You
On Tue, 14 Aug 2012, Tejun Heo wrote:
On Tue, Aug 14, 2012 at 08:55:16PM +0200, Thomas Gleixner wrote:
* mod_delayed_work() can't be used from IRQ handlers.
This function does not exist. So what?
It makes the workqueue users messy. It's difficult to get completely
correct and subtle
On Tue, 14 Aug 2012, Tejun Heo wrote:
On Tue, Aug 14, 2012 at 09:16:16PM +0200, Thomas Gleixner wrote:
Why the hell are you trying to rush stuff which affects a well
maintained part of the kernel through your own tree w/o having the
courtesy of contacting the maintainer politely instead of
Hello, Thomas.
On Tue, Aug 14, 2012 at 10:43:30PM +0200, Thomas Gleixner wrote:
It makes the workqueue users messy. It's difficult to get completely
correct and subtle errors are difficult to detect / verify.
Ah, the function which does not exist makes the users
messy. Interesting
Hello, Thomas.
On Tue, Aug 14, 2012 at 11:03:33PM +0200, Thomas Gleixner wrote:
Why should -next have different rules to mainline?
It's faster paced and trees revert. The message specifically was a
ping for objection and I was waiting for further response and would
have waited until early next
Tejun,
On Tue, 14 Aug 2012, Tejun Heo wrote:
On Tue, Aug 14, 2012 at 11:03:33PM +0200, Thomas Gleixner wrote:
Why should -next have different rules to mainline?
It's faster paced and trees revert. The message specifically was a
Nonsense. It's a tree which gets stuff which is cooked and
Hello, Thomas.
On Wed, Aug 15, 2012 at 12:45:24AM +0200, Thomas Gleixner wrote:
And we have very well worked out mechanisms regarding cross tree
changes, i.e. providing minimal trees to pull for other maintainers.
If you look at the review branches, they're actually structured that
way so that
Tejun,
On Tue, 14 Aug 2012, Tejun Heo wrote:
On Tue, Aug 14, 2012 at 10:43:30PM +0200, Thomas Gleixner wrote:
It makes the workqueue users messy. It's difficult to get completely
correct and subtle errors are difficult to detect / verify.
Ah, the function which does not exist makes
Hello, Thomas.
On Wed, Aug 15, 2012 at 01:12:01AM +0200, Thomas Gleixner wrote:
Just for the record. The thread evolved from here:
tj* mod_delayed_work() can't be used from IRQ handlers.
My answer was:
tglx This function does not exist. So what?
Which was completely
On Tue, 14 Aug 2012, Tejun Heo wrote:
On Wed, Aug 15, 2012 at 12:45:24AM +0200, Thomas Gleixner wrote:
And we have very well worked out mechanisms regarding cross tree
changes, i.e. providing minimal trees to pull for other maintainers.
If you look at the review branches, they're actually
Tejun,
On Tue, 14 Aug 2012, Tejun Heo wrote:
On Wed, Aug 15, 2012 at 01:12:01AM +0200, Thomas Gleixner wrote:
Just for the record. The thread evolved from here:
tj* mod_delayed_work() can't be used from IRQ handlers.
My answer was:
tglx This function does not exist. So
Hello,
On Tue, Aug 14, 2012 at 4:46 PM, Thomas Gleixner t...@linutronix.de wrote:
Do you really expect that I follow all of kernel dev posts within a
day of returning from a two weeks vacation?
The head message says on what it's based on and the git branch. I
can't read your mind or know your
Hello, Thomas.
On Wed, Aug 15, 2012 at 01:33:09AM +0200, Thomas Gleixner wrote:
To convince me to accept your patches you should start answering my
questions and suggestions seriously in the first place and not
discarding them upfront as lunatic visions.
As long as you can't provide a
Hello,
On Wed, Aug 08, 2012 at 11:10:24AM -0700, Tejun Heo wrote:
> Timer internals are protected by irqsafe lock but the lock is
> naturally dropped and irq enabled while a timer is executed. This
> makes dequeueing timer for execution and the actual execution
> non-atomic against IRQs. No
Hello,
On Wed, Aug 08, 2012 at 11:10:24AM -0700, Tejun Heo wrote:
Timer internals are protected by irqsafe lock but the lock is
naturally dropped and irq enabled while a timer is executed. This
makes dequeueing timer for execution and the actual execution
non-atomic against IRQs. No matter
Either I'm keeping forgetting adding Subject: tag or git-send-mail is
somehow screwed up. Sorry about that.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Either I'm keeping forgetting adding Subject: tag or git-send-mail is
somehow screwed up. Sorry about that.
--
tejun
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
42 matches
Mail list logo
