linux-kernel - Re: [patch] mm, thp: add new background defrag option

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <a00566c2-6fe4-90ce-6689-476619c556b8@suse.cz>
Date:   Tue, 10 Jan 2017 09:44:37 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Hugh Dickins <hughd@...gle.com>,
        David Rientjes <rientjes@...gle.com>
Cc:     Mel Gorman <mgorman@...hsingularity.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch] mm, thp: add new background defrag option

On 01/10/2017 04:38 AM, Hugh Dickins wrote:
> On Mon, 9 Jan 2017, David Rientjes wrote:
>> On Mon, 9 Jan 2017, Vlastimil Babka wrote:
>>
>>>> Any suggestions for a better name for "background" are more than welcome.  
>>>
>>> Why not just "madvise+defer"?
>>>
>>
>> Seeing no other activity regarding this issue (omg!), I'll wait a day or 
>> so to see if there are any objections to "madvise+defer" or suggestions 
>> that may be better and repost.
> 
> I get very confused by the /sys/kernel/mm/transparent_hugepage/defrag
> versus enabled flags, and this may be a terrible, even more confusing,
> idea: but I've been surprised and sad to see defrag with a "defer"
> option, but poor enabled without one; and it has crossed my mind that
> perhaps the peculiar "madvise+defer" syntax in defrag might rather be
> handled by "madvise" in defrag with "defer" in enabled?  Or something
> like that: 4 x 4 possibilities instead of 5 x 3.

But would all the possibilities make sense? For example, if I saw
"defer" in enabled, my first expectation would be that it would only use
khugepaged, and no THP page faults at all - possibly including madvised
regions.

If we really wanted really to cover the whole configuration space, we
would have files called "enable", "defrag", "enable-madvise",
"defrag-madvise" and each with possible values "yes", "no", "defer",
where "defer" for enable* files would mean to skip THP page fault
completely and defer to khugepaged, and "defer" for defrag* files would
mean wake up kswapd/kcompactd and skip direct reclaim/compaction.

But, too late for that :)

> 
> Please be gentle with me,
> Hugh
>