linux-kernel - Re: [RFC v2 0/4] Outsourcing compaction for THP allocations to kcompactd

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: <55B5FA31.6050301@suse.cz>
Date:	Mon, 27 Jul 2015 11:30:25 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Rik van Riel <riel@...hat.com>, linux-mm@...ck.org
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Hugh Dickins <hughd@...gle.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Mel Gorman <mgorman@...e.de>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [RFC v2 0/4] Outsourcing compaction for THP allocations to
 kcompactd

On 07/24/2015 04:22 PM, Rik van Riel wrote:
> On 07/02/2015 04:46 AM, Vlastimil Babka wrote:
>> This RFC series is another evolution of the attempt to deal with THP
>> allocations latencies. Please see the motivation in the previous version [1]
>>
>> The main difference here is that I've bitten the bullet and implemented
>> per-node kcompactd kthreads - see Patch 1 for the details of why and how.
>> Trying to fit everything into khugepaged was getting too clumsy, and kcompactd
>> could have more benefits, see e.g. the ideas here [2]. Not everything is
>> implemented yet, though, I would welcome some feedback first.
>
> This leads to a few questions, one of which has an obvious answer.
>
> 1) Why should this functionality not be folded into kswapd?
>
>      (because kswapd can get stuck on IO for long periods of time)

Hm, my main concern was somewhat opposite - kswapd primarily serves to 
avoid direct reclaim (also for) order-0 allocations, so we don't want to 
make it busy compacting for high-order allocations and then fail to 
reclaim quickly enough.
Also the waking up of kswapd for all the distinct tasks would become 
more complex.

Also does kswapd really get stuck on IO? Doesn't it just issue writeback 
and go on? Again it would be the opposite concern, as sync compaction 
may have to wait for writeback before migrating a page and blocking 
kswapd on that wouldn't be nice.

> 2) Given that kswapd can get stuck on IO for long periods of
>      time, are there other tasks we may want to break out of
>      kswapd, in order to reduce page reclaim latencies for things
>      like network allocations?
>
>      (freeing clean inactive pages?)
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/