Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1680455 > unrolled thread

Re: [PATCH mm] introduce reverse buddy concept to reduce buddy fragment

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH mm] introduce reverse buddy concept to reduce buddy  fragment Michal Hocko <mhocko@kernel.org> - 2017-07-03 17:40 +0200
    Re: [PATCH mm] introduce reverse buddy concept to reduce buddy  fragment zhouxianrong <zhouxianrong@huawei.com> - 2017-07-04 03:30 +0200
      Re: [PATCH mm] introduce reverse buddy concept to reduce buddy  fragment Michal Hocko <mhocko@kernel.org> - 2017-07-04 09:00 +0200
        Re: [PATCH mm] introduce reverse buddy concept to reduce buddy  fragment zhouxianrong <zhouxianrong@huawei.com> - 2017-07-04 09:10 +0200
        Re: [PATCH mm] introduce reverse buddy concept to reduce buddy  fragment Michal Hocko <mhocko@kernel.org> - 2017-07-04 13:30 +0200
          Re: [PATCH mm] introduce reverse buddy concept to reduce buddy  fragment Mel Gorman <mgorman@suse.de> - 2017-07-04 13:50 +0200

#1680455 — Re: [PATCH mm] introduce reverse buddy concept to reduce buddy fragment

On Mon 03-07-17 20:02:16, zhouxianrong wrote:
[...]
> from above i think after applying the patch the result is better.

You haven't described your testing methodology, nor the workload that was
tested. As such this data is completely meaningless.

-- 
Michal Hocko
SUSE Labs

[toc] | [next] | [standalone]

#1680633

the test was done as follows:

1. the environment is android 7.0 and kernel is 4.1 and managed memory is 3.5GB
2. every 4s startup one apk, total 100 more apks need to startup
3. after finishing step 2, sample buddyinfo once and get the result

On 2017/7/3 23:33, Michal Hocko wrote:
> On Mon 03-07-17 20:02:16, zhouxianrong wrote:
> [...]
>> from above i think after applying the patch the result is better.
>
> You haven't described your testing methodology, nor the workload that was
> tested. As such this data is completely meaningless.
>

[toc] | [prev] | [next] | [standalone]

#1680698

On Tue 04-07-17 09:21:00, zhouxianrong wrote:
> the test was done as follows:
> 
> 1. the environment is android 7.0 and kernel is 4.1 and managed memory is 3.5GB

There have been many changes in the compaction proper since than. Do you
see the same problem with the current upstream kernel?

> 2. every 4s startup one apk, total 100 more apks need to startup
> 3. after finishing step 2, sample buddyinfo once and get the result

How stable are those results?
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1680704

i do the test again. after minutes i tell you the result.

On 2017/7/4 14:52, Michal Hocko wrote:
> On Tue 04-07-17 09:21:00, zhouxianrong wrote:
>> the test was done as follows:
>>
>> 1. the environment is android 7.0 and kernel is 4.1 and managed memory is 3.5GB
>
> There have been many changes in the compaction proper since than. Do you
> see the same problem with the current upstream kernel?
>
>> 2. every 4s startup one apk, total 100 more apks need to startup
>> 3. after finishing step 2, sample buddyinfo once and get the result
>
> How stable are those results?
>

[toc] | [prev] | [next] | [standalone]

#1680884

On Tue 04-07-17 16:04:52, zhouxianrong wrote:
> every 2s i sample /proc/buddyinfo in the whole test process.
> 
> the last about 90 samples were sampled after the test was done.

I've tried to explain to you that numbers without a proper testing
metodology and highlevel metrics you are interested in and comparision
to the base kernel are meaningless. I cannot draw any conclusion from
looking at numbers you have posted. Are high order allocations cheaper
to do with this patch? What about an averge order-0 allocation request?

You are touching memory allocator hot paths and those are really
sensitive to changes. It takes a lot of testing with different workloads
to prove that no new regressions are introduced. That being said, I
completely agree that reducing the memory fragmentation is an important
objective but touching the page allocator and adding new branches there
sounds like a problematic approach which would have to show _huge_
benefits to be mergeable. Is it possible to improve khugepaged to
accomplish the same thing?
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1680890

On Tue, Jul 04, 2017 at 01:24:14PM +0200, Michal Hocko wrote:
> On Tue 04-07-17 16:04:52, zhouxianrong wrote:
> > every 2s i sample /proc/buddyinfo in the whole test process.
> > 
> > the last about 90 samples were sampled after the test was done.
> 
> I've tried to explain to you that numbers without a proper testing
> metodology and highlevel metrics you are interested in and comparision
> to the base kernel are meaningless. I cannot draw any conclusion from
> looking at numbers you have posted. Are high order allocations cheaper
> to do with this patch? What about an averge order-0 allocation request?
> 

I have to agree. The patch is extremely complex for what it does which
is working around a limitation of the buddy allocator in general
(buddy's must be naturally aligned). There would have to be *strong*
justification that allocations fail even with compaction or a reclaim
cycle or that the latency is severely reduced -- neither which is
evident from the data presented. It would also have to be proven that
there is no overhead added in the general case to justify this so
without extensive justification for the complexity;

Naked-by: Mel Gorman <mgorman@suse.de>

> You are touching memory allocator hot paths and those are really
> sensitive to changes. It takes a lot of testing with different workloads
> to prove that no new regressions are introduced. That being said, I
> completely agree that reducing the memory fragmentation is an important
> objective but touching the page allocator and adding new branches there
> sounds like a problematic approach which would have to show _huge_
> benefits to be mergeable. Is it possible to improve khugepaged to
> accomplish the same thing?

Or if this is CMA related, a justification why alloc_contig_range cannot do
the same thing with a linear walk when the initial allocation attempt fails.

-- 
Mel Gorman
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web