On Thu, 26 Jul 2012, Peter Boonstoppel wrote:
> > > tglx has patches that make the kthread create/destroy stuff from hotplug
> > > go away.. that seems like the better approach.
>
> > Right. That cpu hotplug setup/teardown stuff is ugly.
>
> If that stuff gets removed complete that's great. The
On Thu, 26 Jul 2012, Peter Boonstoppel wrote:
tglx has patches that make the kthread create/destroy stuff from hotplug
go away.. that seems like the better approach.
Right. That cpu hotplug setup/teardown stuff is ugly.
If that stuff gets removed complete that's great. The only
> > tglx has patches that make the kthread create/destroy stuff from hotplug
> > go away.. that seems like the better approach.
> Right. That cpu hotplug setup/teardown stuff is ugly.
If that stuff gets removed complete that's great. The only change I'm aware of
right now is the workqueue one:
On Thu, 2012-07-26 at 17:54 +0200, Oleg Nesterov wrote:
> Yes, but this "avoid the preemption after wakeup" can actually help
> kthread_bind()->wait_task_inactive() ?
Yeah.
> This reminds me, Peter had a patch which teaches wait_task_inactive()
> to use sched_in/sched_out notifiers to avoid the
On 07/26, Thomas Gleixner wrote:
>
> On Thu, 26 Jul 2012, Peter Zijlstra wrote:
> > On Wed, 2012-07-25 at 15:40 -0700, Tejun Heo wrote:
> > > > This patch disables preemption during complete(), since we call
> > > > schedule() directly afterwards, so it will correctly enter
> > > >
On Thu, 26 Jul 2012, Peter Zijlstra wrote:
> On Wed, 2012-07-25 at 15:40 -0700, Tejun Heo wrote:
> > > This patch disables preemption during complete(), since we call
> > > schedule() directly afterwards, so it will correctly enter
> > > TASK_UNINTERRUPTIBLE. This speeds up kthread
On Wed, 2012-07-25 at 15:40 -0700, Tejun Heo wrote:
> (cc'ing Oleg and Peter)
Right, if you're playing games with preemption, always add the rt and
sched folks.. added mingo and tglx.
> On Wed, Jul 25, 2012 at 03:35:32PM -0700, Peter Boonstoppel wrote:
> > After a kthread is created it signals
On Wed, 2012-07-25 at 15:40 -0700, Tejun Heo wrote:
(cc'ing Oleg and Peter)
Right, if you're playing games with preemption, always add the rt and
sched folks.. added mingo and tglx.
On Wed, Jul 25, 2012 at 03:35:32PM -0700, Peter Boonstoppel wrote:
After a kthread is created it signals the
On Thu, 26 Jul 2012, Peter Zijlstra wrote:
On Wed, 2012-07-25 at 15:40 -0700, Tejun Heo wrote:
This patch disables preemption during complete(), since we call
schedule() directly afterwards, so it will correctly enter
TASK_UNINTERRUPTIBLE. This speeds up kthread creation/binding during
On 07/26, Thomas Gleixner wrote:
On Thu, 26 Jul 2012, Peter Zijlstra wrote:
On Wed, 2012-07-25 at 15:40 -0700, Tejun Heo wrote:
This patch disables preemption during complete(), since we call
schedule() directly afterwards, so it will correctly enter
TASK_UNINTERRUPTIBLE. This
On Thu, 2012-07-26 at 17:54 +0200, Oleg Nesterov wrote:
Yes, but this avoid the preemption after wakeup can actually help
kthread_bind()-wait_task_inactive() ?
Yeah.
This reminds me, Peter had a patch which teaches wait_task_inactive()
to use sched_in/sched_out notifiers to avoid the
tglx has patches that make the kthread create/destroy stuff from hotplug
go away.. that seems like the better approach.
Right. That cpu hotplug setup/teardown stuff is ugly.
If that stuff gets removed complete that's great. The only change I'm aware of
right now is the workqueue one:
(cc'ing Oleg and Peter)
On Wed, Jul 25, 2012 at 03:35:32PM -0700, Peter Boonstoppel wrote:
> After a kthread is created it signals the requester using complete()
> and enters TASK_UNINTERRUPTIBLE. However, since complete() wakes up
> the requesting thread this can cause a preemption. The
After a kthread is created it signals the requester using complete()
and enters TASK_UNINTERRUPTIBLE. However, since complete() wakes up
the requesting thread this can cause a preemption. The preemption will
not remove the task from the runqueue (for that schedule() has to be
invoked directly).
After a kthread is created it signals the requester using complete()
and enters TASK_UNINTERRUPTIBLE. However, since complete() wakes up
the requesting thread this can cause a preemption. The preemption will
not remove the task from the runqueue (for that schedule() has to be
invoked directly).
(cc'ing Oleg and Peter)
On Wed, Jul 25, 2012 at 03:35:32PM -0700, Peter Boonstoppel wrote:
After a kthread is created it signals the requester using complete()
and enters TASK_UNINTERRUPTIBLE. However, since complete() wakes up
the requesting thread this can cause a preemption. The preemption
Hello,
On Tue, Jul 24, 2012 at 05:05:32PM -0700, Peter Boonstoppel wrote:
> After a kthread is created it signals the requester using complete()
> and enters TASK_UNINTERRUPTIBLE. However, since complete() wakes up
> the requesting thread this can cause a preemption. The preemption will
> not
After a kthread is created it signals the requester using complete()
and enters TASK_UNINTERRUPTIBLE. However, since complete() wakes up
the requesting thread this can cause a preemption. The preemption will
not remove the task from the runqueue (for that schedule() has to be
invoked directly).
After a kthread is created it signals the requester using complete()
and enters TASK_UNINTERRUPTIBLE. However, since complete() wakes up
the requesting thread this can cause a preemption. The preemption will
not remove the task from the runqueue (for that schedule() has to be
invoked directly).
Hello,
On Tue, Jul 24, 2012 at 05:05:32PM -0700, Peter Boonstoppel wrote:
After a kthread is created it signals the requester using complete()
and enters TASK_UNINTERRUPTIBLE. However, since complete() wakes up
the requesting thread this can cause a preemption. The preemption will
not remove
20 matches
Mail list logo
