On Wednesday 09 July 2008 20:53, Gregory Haskins wrote:

quoted

quoted

quoted

On Wed, Jul 9, 2008 at  4:09 AM, in message

[ref], Nick Piggin

[off-list ref] wrote:

quoted

On Tuesday 08 July 2008 22:37, Gregory Haskins wrote:

quoted

quoted

quoted

quoted

On Tue, Jul 8, 2008 at  1:00 AM, in message

[ref], Nick Piggin

[off-list ref] wrote:

quoted

On Saturday 28 June 2008 06:29, Gregory Haskins wrote:

quoted

Inspired by Peter Zijlstra.

Signed-off-by: Gregory Haskins <redacted>

What happened to the feedback I sent about this?

It is still nack from me.

Ah yes.  Slipped through the cracks...sorry about that.

What if we did "if (idle == CPU_NEWLY_IDLE && need_resched())" instead?

Isn't that exactly the same thing

Not quite.  The former version would break on *any* succesful enqueue (as a
result of a local move_task as well as a remote wake-up/migration).  The
latter version will only break on the the remote variety.  You were
concerned about stopping a move_task operation early because it would
reduce efficiency, and I do not entirely disagree. However, this really
only concerns the local type (which have now been removed).

Remote preemptions should (IMO) always break immediately because it would
have been likely to invalidate the f_b_g() calculation anyway, and
low-latency requirements dictate its the right thing to do.

I thought this was about newidle balancing? Tasks are always going to
be coming from remote runqueues, aren't they?

quoted

because any task will preempt the idle thread?

During NEWIDLE this is a preempt-disabled section because we are still in
the middle of a schedule(). Therefore there will be no involuntary
preemption and that is why we are concerned with making sure we check for
voluntary preemption.  The move_tasks() will run to completion without this
patch.  With this patch it will break the operation if someone tries to
preempt us.

Firstly, won't the act of pulling tasks set the need_resched condition?

Secondly, even if it does what you say, what exactly would be the difference
between blocking a newly moved task from running and blocking a newly woken
task from running? Either way you introduce the same worst case latency
condition.

I'll keep an open mind but I am pretty sure this is something we should be
doing. As far as I can tell, there should be no downside with this second
version. 

I don't think it has really been thought through that well. So I'm still
against it.

As a compromise we could put an #ifdef CONFIG_PREEMPT around this 
new logic, but I don't think it is strictly necessary.

That's not very nice. It's reasonable to run with CONFIG_PREEMPT but not
blindly want to trade latency for throughput.