linux-kernel - Re: [PATCH 02/40] mm: slab allocation fairness

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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0705161338040.11168@schroedinger.engr.sgi.com>
Date:	Wed, 16 May 2007 13:41:32 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	netdev@...r.kernel.org,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Thomas Graf <tgraf@...g.ch>,
	David Miller <davem@...emloft.net>,
	James Bottomley <James.Bottomley@...elEye.com>,
	Mike Christie <michaelc@...wisc.edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Phillips <phillips@...gle.com>
Subject: Re: [PATCH 02/40] mm: slab allocation fairness

On Fri, 4 May 2007, Peter Zijlstra wrote:

> Page allocation rank is a scalar quantity connecting ALLOC_ and gfp flags which
> represents how deep we had to reach into our reserves when allocating a page. 
> Rank 0 is the deepest we can reach (ALLOC_NO_WATERMARK) and 16 is the most 
> shallow allocation possible (ALLOC_WMARK_HIGH).
> 
> When the slab space is grown the rank of the page allocation is stored. For
> each slab allocation we test the given gfp flags against this rank. Thereby
> asking the question: would these flags have allowed the slab to grow.
> 
> If not so, we need to test the current situation. This is done by forcing the
> growth of the slab space. (Just testing the free page limits will not work due
> to direct reclaim) Failing this we need to fail the slab allocation.

This implies that an allocation at time t2 must be aware of the result of 
an allocation at time t1. It assumes a linear ordering of allocations that 
is not possible on large systems. Ordering of events is a very expensive 
endeavor in particular on NUMA systems given the potentially large 
latencies between various portions of the system.

Maybe you need to restrict the ordering per cpu or per node? Per zone? 

Then we would need to store the ranks somewhere which raises scalability 
issues if these are global.


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