[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <517607AD.2010902@linux.vnet.ibm.com>
Date: Tue, 23 Apr 2013 12:01:49 +0800
From: Michael Wang <wangyun@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>, Mike Galbraith <efault@....de>,
Alex Shi <alex.shi@...el.com>,
Namhyung Kim <namhyung@...nel.org>,
Paul Turner <pjt@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>,
Ram Pai <linuxram@...ibm.com>
Subject: Re: [PATCH] sched: wake-affine throttle
On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
>
> OK,.. Ingo said that pipe-test was the original motivation for
> wake_affine() and since that's currently broken to pieces due to
> select_idle_sibling() is there still a benefit to having it at all?
>
> Can anybody find any significant regression when simply killing
> wake_affine()?
IMHO, reserve this stuff may be a better choice, it do bring benefit,
pgbench is just some workload it also bring damage.
By throttle, we could reduce the damage meanwhile reserve the benefit,
when reach some rate, they will be balanced and show best performance, I
suppose just killing the stuff won't show that peak...
Besides, we still have many theory about the possible benefit of this
stuff, along with some side-effect like speared behaviour, it has been
there too long, the influence of killing it is unmeasurable (tend to be
worse), I really prefer to reserve it...
And if we really want to kill it, we could just throttle it with an
incredible interval, and make it unable to breathe any more ;-)
Regards,
Michael Wang
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists