linux-kernel - Re: [PATCH 00/23] per device dirty throttling -v9

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: <1187335158.6114.119.camel@twins>
Date:	Fri, 17 Aug 2007 09:19:17 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Christoph Lameter <clameter@....com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	miklos@...redi.hu, akpm@...ux-foundation.org, neilb@...e.de,
	dgc@....com, tomoki.sekiyama.qu@...achi.com, nikita@...sterfs.com,
	trond.myklebust@....uio.no, yingchao.zhou@...il.com,
	richard@....demon.co.uk, torvalds@...ux-foundation.org, pj@....com
Subject: Re: [PATCH 00/23] per device dirty throttling -v9

On Thu, 2007-08-16 at 14:29 -0700, Christoph Lameter wrote:
> Is there any way to make the global limits on which the dirty rate 
> calculations are based cpuset specific?
> 
> A process is part of a cpuset and that cpuset has only a fraction of 
> memory of the whole system. 
> 
> And only a fraction of that fraction can be dirtied. We do not currently 
> enforce such limits which can cause the amount of dirty pages in 
> cpusets to become excessively high. I have posted several patchsets that 
> deal with that issue. See http://lkml.org/lkml/2007/1/16/5
> 
> It seems that limiting dirty pages in cpusets may be much easier to 
> realize in the context of this patchset. The tracking of the dirty pages 
> per node is not necessary if one would calculate the maximum amount of 
> dirtyable pages in a cpuset and use that as a base, right?


Currently we do: 
  dirty = total_dirty * bdi_completions_p * task_dirty_p

As dgc pointed out before, there is the issue of bdi/task correlation,
that is, we do not track task dirty rates per bdi, so now a task that
heavily dirties on one bdi will also get penalised on the others (and
similar issues).

If we were to change it so:
  dirty = cpuset_dirty * bdi_completions_p * task_dirty_p

We get additional correlation issues: cpuset/bdi, cpuset/task.
Which could yield surprising results if some bdis are strictly per
cpuset.

The cpuset/task correlation has a strict mapping and could be solved by
keeping the vm_dirties counter per cpuset. However, this would seriously
complicate the code and I'm not sure if it would gain us much.

Anyway, things to ponder. But overall it should be quite doable.


Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)