Re: [PATCH] sched: smpnice work around for active_load_balance()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Siddha, Suresh B wrote:
On Mon, Apr 03, 2006 at 11:04:52AM +1000, Peter Williams wrote:
Peter Williams wrote:
I gave an example in a previous e-mail. Basically, at the end of scheduler_tick() if rebalance_tick() doesn't move any tasks (it would be foolish to contemplate moving tasks of the queue just after you've moved some there) and the run queue has exactly one running task and it's time for a HT/MC rebalance check on the package that this run queue belongs to then check that package to to see if it meets the rest of criteria for needing to lose some tasks. If it does look for a package that is a suitable recipient for the moved task and if you find one then mark this run queue as needing active load balancing and arrange for its migration thread to be started.

Simple, direct and amenable to being only built on architectures that need the functionality.
Are you working on this idea or should I do it?

my issues raised in response to this idea are unanswered.

<issues>
First of all we will be doing unnecessary checks to see if there is
an imbalance..

There will be saved overhead when the current code is removed that can be used. Also, if you examine the idea you'll find that it would be very cheap and the possibilities for early abandonment of the checks would make them very efficient.

Current code triggers the checks and movement only when
it is necessary..

That is untrue.  The best you can say is when they MIGHT be necessary.

And second, finding the correct destination cpu in the presence of SMT and MC is really complicated.. Look at different examples
in the OLS paper.. Domain topology provides all this info with no added
complexity...

This to me would seem to be an argument in favour of change rather than an argument for retaining the current highly random process.

Finding the appropriate destination package/queue can be left to active_load_balance() and this would reduce the impact of the inherent raciness of load balancing.

</issues>

I don't see a merit and so I am not looking into this.

OK.  I'll do it.

Peter
--
Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux