On 01/14/2016 12:07 AM, Andrey Belevantsev wrote:
Hello Bernd,
On 13.01.2016 21:25, Bernd Schmidt wrote:
There are a few open PRs involving sel-sched, and I'd like to start a
discussion about removing it. Having two separate schedulers isn't a very
good idea in the first place IMO, and since ia64 is dead, sel-sched gets
practically no testing despite being the more complex one.
Thoughts?
Out of the PRs we have, two are actually fixed but not marked as such.
This year's PRs are from the recent Zdenek's Debian rebuild with GCC 6
and I will be on them now. For the other two last year PRs, it is my
fault not to fix them in a timely manner. Frankly, 2015 was very tough
for me and my colleagues (we worked 6 days a week most part of the
year), but since January it is fine again and we'll catch up now. Sorry
for that.
You're also right that sel-sched now gets limited testing. We're made
it work initially for ia64, x64, ppc and cell, and then added ARM, too.
Outside of ia64 world, I had private reports of sel-sched being used for
cell with success, and we used it in our own contractor work for
optimizing some ARM apps with GCC.
In short, we're willing to maintain sel-sched and I apologize for the
slow PR fixing speed last year, it should be no problem anymore as of
now. If there are any big plans of reorganizing schedulers and
sel-sched stands in the way of those, let's discuss it and we'll be
willing to help in any way.
FWIW, I've downgraded the sel-sched stuff to P4 for this release given
how that scheduler is typically used (ia64, which is a dead platform).
I think the bigger question Bernd is asking here is whether or not it
makes sense to have multiple schedulers. In an ideal world we'd bake
them off select the best and deprecate/remove the others.
I didn't follow sel-sched development closely, so forgive me if the
questions are simplistic/naive, but what are the main benefits of
sel-sched and is it at a point (performance-wise) where it could
conceivably replace the aging haifa scheduler infrastructure?
Jeff
