date:20180130

Re: [RFC] mm/migrate: Add new migration reason MR_HUGETLB

2018-01-30 Thread Michal Hocko

On Tue 30-01-18 08:37:14, Anshuman Khandual wrote:
> alloc_contig_range() initiates compaction and eventual migration for
> the purpose of either CMA or HugeTLB allocation. At present, reason
> code remains the same MR_CMA for either of those cases. Lets add a
> new reason code which will differentiate the purpose of migration
> as HugeTLB allocation instead.

Why do we need it?

> Signed-off-by: Anshuman Khandual 
> ---
>  include/linux/migrate.h|  1 +
>  include/trace/events/migrate.h |  3 ++-
>  mm/page_alloc.c| 14 ++
>  3 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index a732598fcf83..44381c33a2bd 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -26,6 +26,7 @@ enum migrate_reason {
>   MR_MEMPOLICY_MBIND,
>   MR_NUMA_MISPLACED,
>   MR_CMA,
> + MR_HUGETLB,
>   MR_TYPES
>  };
>  
> diff --git a/include/trace/events/migrate.h b/include/trace/events/migrate.h
> index bcf4daccd6be..61474c93f8f3 100644
> --- a/include/trace/events/migrate.h
> +++ b/include/trace/events/migrate.h
> @@ -20,7 +20,8 @@
>   EM( MR_SYSCALL, "syscall_or_cpuset")\
>   EM( MR_MEMPOLICY_MBIND, "mempolicy_mbind")  \
>   EM( MR_NUMA_MISPLACED,  "numa_misplaced")   \
> - EMe(MR_CMA, "cma")
> + EM( MR_CMA, "cma")  \
> + EMe(MR_HUGETLB, "hugetlb")
>  
>  /*
>   * First define the enums in the above macros to be exported to userspace
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 242565855d05..ce8a2f2d4994 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7588,13 +7588,14 @@ static unsigned long pfn_max_align_up(unsigned long 
> pfn)
>  
>  /* [start, end) must belong to a single zone. */
>  static int __alloc_contig_migrate_range(struct compact_control *cc,
> - unsigned long start, unsigned long end)
> + unsigned long start, unsigned long end,
> + unsigned migratetype)
>  {
>   /* This function is based on compact_zone() from compaction.c. */
>   unsigned long nr_reclaimed;
>   unsigned long pfn = start;
>   unsigned int tries = 0;
> - int ret = 0;
> + int ret = 0, migrate_reason = 0;
>  
>   migrate_prep();
>  
> @@ -7621,8 +7622,13 @@ static int __alloc_contig_migrate_range(struct 
> compact_control *cc,
>   &cc->migratepages);
>   cc->nr_migratepages -= nr_reclaimed;
>  
> + if (migratetype == MIGRATE_CMA)
> + migrate_reason = MR_CMA;
> + else
> + migrate_reason = MR_HUGETLB;
> +
>   ret = migrate_pages(&cc->migratepages, new_page_alloc_contig,
> - NULL, 0, cc->mode, MR_CMA);
> + NULL, 0, cc->mode, migrate_reason);
>   }
>   if (ret < 0) {
>   putback_movable_pages(&cc->migratepages);
> @@ -7710,7 +7716,7 @@ int alloc_contig_range(unsigned long start, unsigned 
> long end,
>* allocated.  So, if we fall through be sure to clear ret so that
>* -EBUSY is not accidentally used or returned to caller.
>*/
> - ret = __alloc_contig_migrate_range(&cc, start, end);
> + ret = __alloc_contig_migrate_range(&cc, start, end, migratetype);
>   if (ret && ret != -EBUSY)
>   goto done;
>   ret =0;
> -- 
> 2.11.0
> 

-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK

2018-01-30 Thread Vincent Guittot

On 29 January 2018 at 19:43, Dietmar Eggemann  wrote:
> On 01/24/2018 09:25 AM, Vincent Guittot wrote:
>>
>> Hi,
>>
>> Le Thursday 18 Jan 2018 à 10:38:07 (+), Morten Rasmussen a écrit :
>>>
>>> On Mon, Jan 15, 2018 at 09:26:09AM +0100, Vincent Guittot wrote:

 Le Wednesday 03 Jan 2018 à 10:16:00 (+0100), Vincent Guittot a écrit :
>
>
> [...]
>
>

 Hi Peter,

 With the patch below on top of your branch, the blocked loads are
 updated and
 decayed regularly. The main differences are:
 - It doesn't use a timer to trig ilb but the tick and when a cpu becomes
 idle.
The main drawback of this solution is that the load is blocked when
 the
system is fully idle with the advantage of not waking up a fully idle
system. We have to wait for the next tick or newly idle event for
 updating
blocked load when the system leaves idle stat which can be up to a
 tick long.
If this is too long, we can check for kicking ilb when task wakes up
 so the
blocked load will be updated as soon as the system leaves idle state.
The main advantage is that we don't wake up a fully idle system every
 32ms to
update blocked load that will be not used.
 - I'm working on one more improvement to use nohz_idle_balance in the
 newly
idle case when the system is not overloaded and
(this_rq->avg_idle > sysctl_sched_migration_cost). In this case, we
 can try to
use nohz_idle_balance with NOHZ_STATS_KICK and abort as soon as it
 exceed
this_rq->avg_idle. This will remove some calls to kick_ilb and some
 wake up
of an idle cpus.
>>>
>>>
>>> This sound like what I meant in my other reply :-)
>>>
>>> It seems pointless to have a timer to update PELT if the system is
>>> completely idle, and when it isn't we can piggy back other events to
>>> make the updates happen.
>>
>>
>> The patch below implements what has been described above. It calls part of
>> nohz_idle_balance when a cpu becomes idle and kick a ilb if it takes too
>> much
>> time. This removes part of ilb that are kicked on an idle cpu for updating
>> the blocked load but the ratio really depends on when the tick happens
>> compared
>> to a cpu becoming idle and the 32ms boundary. I have an additionnal patch
>> that
>> enables to update the blocked loads when a cpu becomes idle 1 period
>> before
>> kicking an ilb and there is far less ilb because we give more chance to
>> the
>> newly idle case (time_after is replaced by time_after_eq in
>> idle_balance()).
>>
>> The patch also uses a function cfs_rq_has_blocked, which only checks the
>> util/load_avg, instead of the cfs_rq_is_decayed which check *_sum too.
>> This
>> reduce significantly the number of update of blocked load. the *_avg will
>> be
>> fully decayed in around 300~400ms but it's far longer for the *_sum which
>> have
>> a higher resolution and we can easily reach almost seconds. But only the
>> *_avg
>> are used to make decision so keeping some blocked *_sum is acceptable.
>>
>> ---
>>   kernel/sched/fair.c | 121
>> +++-
>>   1 file changed, 92 insertions(+), 29 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 898785d..ed90303 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -7356,6 +7356,17 @@ static inline bool cfs_rq_is_decayed(struct cfs_rq
>> *cfs_rq)
>> return true;
>>   }
>>   +static inline bool cfs_rq_has_blocked(struct cfs_rq *cfs_rq)
>> +{
>> +   if (cfs_rq->avg.load_avg)
>> +   return true;
>> +
>> +   if (cfs_rq->avg.util_avg)
>> +   return true;
>> +
>> +   return false;
>> +}
>> +
>
>
> Can we not change cfs_rq_is_decayed() to use avg.foo_avg instead of
> avg.foo_sum ?

I don't think so because the *_sum are used to keep coherency bewteen
cfs_rq and cgroups when task migrates and are enqueued/dequeued so wwe
can't remove it until the *_sum are null otherwise the all cfs_rq and
group will be out of sync

>
>>   #ifdef CONFIG_FAIR_GROUP_SCHED
>> static void update_blocked_averages(int cpu)
>> @@ -7393,7 +7404,9 @@ static void update_blocked_averages(int cpu)
>>  */
>> if (cfs_rq_is_decayed(cfs_rq))
>> list_del_leaf_cfs_rq(cfs_rq);
>> -   else
>> +
>> +   /* Don't need periodic decay once load/util_avg are null
>> */
>> +   if (cfs_rq_has_blocked(cfs_rq))
>> done = false;
>> }
>>   @@ -7463,7 +7476,7 @@ static inline void update_blocked_averages(int
>> cpu)
>> update_cfs_rq_load_avg(cfs_rq_clock_task(cfs_rq), cfs_rq);
>>   #ifdef CONFIG_NO_HZ_COMMON
>> rq->last_blocked_load_update_tick = jiffies;
>> -   if (cfs_rq_is_decayed(cfs_rq))
>> +   if (cfs_rq_has_blocked(cfs_rq))
>
>
> Schouldn't this be !cfs_rq_has_blocked(cfs_rq) ?

yes. I copy/

Re: [PATCH v2] of: use hash based search in of_find_node_by_phandle

2018-01-30 Thread Chintan Pandya

(1)

Can you point me to the driver code that is invoking
the search?

There are many locations. Few of them being,
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/of/irq.c?h=msm-4.9#n214
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/irqchip/irq-gic-v3.c?h=msm-4.9#n1107
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/clk/msm/msm-clock-controller.c?h=msm-4.9#n492

(2)

And also the .dts devicetree source file that you are seeing
large overhead with.

SDM670 DTS tree starts here.
https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/arch/arm64/boot/dts/qcom/sdm670.dtsi?h=msm-4.9

(3) -- this one is less important, but if the info is easily
available to you

Sorry about dribbling out questions instead of all at once

What is the hardware you are testing this on?

SDM670

Processor?

Kryo-300 Silver

Cache size?

From DT,
L1 32KB (per CPU)
L2 128KB (per CPU)
L3 1MB (total)

Memory size?

6GB

Processor frequency?

Max 1.7GHz for core 0. Not sure about boot time frequency.

Any other attribute of the system that will help me understand
the boot performance you are seeing?

I'm not able to profile of_find_node_by_phandle specifically as timers are
not up by then. So, just observing overall boot time for comparison.

My recent results were taken on debug_defconfig which has many performance
slowing code. So, gap between base-build and w/ the test patches would be
more than the actual production build.

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 994 matches

Mail list logo