On Thu, Nov 14, 2013 at 10:49:02AM +, Morten Rasmussen wrote:
> We need a way to know which group of cpus the flag applies to. If we
> don't want to pass a pointer to the sched_domain and we want to replace
> the current named sched_domain levels with something more flexible, the
> only solutio
On Wed, Nov 13, 2013 at 04:29:19PM +, Peter Zijlstra wrote:
> On Wed, Nov 13, 2013 at 03:47:16PM +, Dietmar Eggemann wrote:
> > On 12/11/13 18:08, Peter Zijlstra wrote:
> > > On Tue, Nov 12, 2013 at 05:43:36PM +, Dietmar Eggemann wrote:
> > >> This patch removes the sched_domain initial
On Wed, Nov 13, 2013 at 03:47:16PM +, Dietmar Eggemann wrote:
> On 12/11/13 18:08, Peter Zijlstra wrote:
> > On Tue, Nov 12, 2013 at 05:43:36PM +, Dietmar Eggemann wrote:
> >> This patch removes the sched_domain initializer macros
> >> SD_[SIBLING|MC|BOOK|CPU]_INIT in core.c and in archs an
On 12/11/13 18:08, Peter Zijlstra wrote:
> On Tue, Nov 12, 2013 at 05:43:36PM +, Dietmar Eggemann wrote:
>> This patch removes the sched_domain initializer macros
>> SD_[SIBLING|MC|BOOK|CPU]_INIT in core.c and in archs and replaces them
>> with calls to the new function sd_init(). The function
On Tue, Nov 12, 2013 at 05:43:36PM +, Dietmar Eggemann wrote:
> This patch removes the sched_domain initializer macros
> SD_[SIBLING|MC|BOOK|CPU]_INIT in core.c and in archs and replaces them
> with calls to the new function sd_init(). The function sd_init
> incorporates the already existing f
On 06/11/13 14:08, Peter Zijlstra wrote:
> On Wed, Nov 06, 2013 at 02:53:44PM +0100, Martin Schwidefsky wrote:
>> On Tue, 5 Nov 2013 23:27:52 +0100
>> Peter Zijlstra wrote:
>>
>>> On Tue, Nov 05, 2013 at 03:57:23PM +0100, Vincent Guittot wrote:
Your proposal looks fine for me. It's clearly be
On Wed, Nov 06, 2013 at 02:53:44PM +0100, Martin Schwidefsky wrote:
> On Tue, 5 Nov 2013 23:27:52 +0100
> Peter Zijlstra wrote:
>
> > On Tue, Nov 05, 2013 at 03:57:23PM +0100, Vincent Guittot wrote:
> > > Your proposal looks fine for me. It's clearly better to move in one
> > > place the configur
On Tue, 5 Nov 2013 23:27:52 +0100
Peter Zijlstra wrote:
> On Tue, Nov 05, 2013 at 03:57:23PM +0100, Vincent Guittot wrote:
> > Your proposal looks fine for me. It's clearly better to move in one
> > place the configuration of sched_domain fields. Have you already got
> > an idea about how to let
On 5 November 2013 23:27, Peter Zijlstra wrote:
> On Tue, Nov 05, 2013 at 03:57:23PM +0100, Vincent Guittot wrote:
>> Your proposal looks fine for me. It's clearly better to move in one
>> place the configuration of sched_domain fields. Have you already got
>> an idea about how to let architecture
On Tue, Nov 05, 2013 at 03:57:23PM +0100, Vincent Guittot wrote:
> Your proposal looks fine for me. It's clearly better to move in one
> place the configuration of sched_domain fields. Have you already got
> an idea about how to let architecture override the topology?
Maybe something like the belo
On 5 November 2013 15:06, Peter Zijlstra wrote:
> On Fri, Oct 18, 2013 at 01:52:15PM +0200, Vincent Guittot wrote:
>> The function arch_sd_local_flags is used to set flags in sched_domains
>> according to the platform architecture. A new flag SD_SHARE_POWERDOMAIN is
>> also created to reflect whet
On Fri, Oct 18, 2013 at 01:52:15PM +0200, Vincent Guittot wrote:
> The function arch_sd_local_flags is used to set flags in sched_domains
> according to the platform architecture. A new flag SD_SHARE_POWERDOMAIN is
> also created to reflect whether groups of CPUs in a sched_domain level can or
> no
The function arch_sd_local_flags is used to set flags in sched_domains
according to the platform architecture. A new flag SD_SHARE_POWERDOMAIN is
also created to reflect whether groups of CPUs in a sched_domain level can or
not reach different power state. As an example, the flag should be cleared
13 matches
Mail list logo
