linux-kernel - Re: [PATCH 18/18] mm: vmscan: remove memcg stalling on writeback pages during direct reclaim

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: <20150323052722.GB8991@htj.duckdns.org>
Date:	Mon, 23 Mar 2015 01:27:22 -0400
From:	Tejun Heo <tj@...nel.org>
To:	axboe@...nel.dk
Cc:	linux-kernel@...r.kernel.org, jack@...e.cz, hch@...radead.org,
	hannes@...xchg.org, linux-fsdevel@...r.kernel.org,
	vgoyal@...hat.com, lizefan@...wei.com, cgroups@...r.kernel.org,
	linux-mm@...ck.org, mhocko@...e.cz, clm@...com,
	fengguang.wu@...el.com, david@...morbit.com, gthelen@...gle.com,
	Vladimir Davydov <vdavydov@...allels.com>
Subject: Re: [PATCH 18/18] mm: vmscan: remove memcg stalling on writeback
 pages during direct reclaim

On Mon, Mar 23, 2015 at 01:07:47AM -0400, Tejun Heo wrote:
> Because writeback wasn't cgroup aware before, the usual dirty
> throttling mechanism in balance_dirty_pages() didn't work for
> processes under memcg limit.  The writeback path didn't know how much
> memory is available or how fast the dirty pages are being written out
> for a given memcg and balance_dirty_pages() didn't have any measure of
> IO back pressure for the memcg.
> 
> To work around the issue, memcg implemented an ad-hoc dirty throttling
> mechanism in the direct reclaim path by stalling on pages under
> writeback which are encountered during direct reclaim scan.  This is
> rather ugly and crude - none of the configurability, fairness, or
> bandwidth-proportional distribution of the normal path.
> 
> The previous patches implemented proper memcg aware dirty throttling
> and the ad-hoc mechanism is no longer necessary.  Remove it.

Oops, just realized that this can't be removed, at least yet.
!unified path still depends on it.  I'll update the patch to disable
these checks only on the unified hierarchy.

Thanks.

-- 
tejun
--
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/