linux-kernel - Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Sep 2019 14:20:30 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     virtio-dev@...ts.oasis-open.org, kvm@...r.kernel.org,
        mst@...hat.com, catalin.marinas@....com, david@...hat.com,
        dave.hansen@...el.com, linux-kernel@...r.kernel.org,
        willy@...radead.org, linux-mm@...ck.org, akpm@...ux-foundation.org,
        will@...nel.org, linux-arm-kernel@...ts.infradead.org,
        osalvador@...e.de, yang.zhang.wz@...il.com, pagupta@...hat.com,
        konrad.wilk@...cle.com, nitesh@...hat.com, riel@...riel.com,
        lcapitulino@...hat.com, wei.w.wang@...el.com, aarcange@...hat.com,
        ying.huang@...el.com, pbonzini@...hat.com,
        dan.j.williams@...el.com, fengguang.wu@...el.com,
        alexander.h.duyck@...ux.intel.com, kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future
 coalescing

On Sat 07-09-19 10:25:20, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@...ux.intel.com>
> 
> Move the head/tail adding logic out of the shuffle code and into the
> __free_one_page function since ultimately that is where it is really
> needed anyway. By doing this we should be able to reduce the overhead
> and can consolidate all of the list addition bits in one spot.

This changelog doesn't really explain why we want this. You are
reshuffling the code, allright, but why do we want to reshuffle? Is the
result readability a better code reuse or something else? Where
does the claimed reduced overhead coming from?

>From a quick look buddy_merge_likely looks nicer than the code splat
we have. Good.

But then

> Reviewed-by: Dan Williams <dan.j.williams@...el.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@...ux.intel.com>

[...]

> -	if (is_shuffle_order(order))
> -		add_to_free_area_random(page, &zone->free_area[order],
> -				migratetype);
> +	area = &zone->free_area[order];
> +	if (is_shuffle_order(order) ? shuffle_pick_tail() :
> +	    buddy_merge_likely(pfn, buddy_pfn, page, order))

Ouch this is just awful don't you think?
-- 
Michal Hocko
SUSE Labs