linux-kernel - Re: The performance and behaviour of the anti-fragmentation related patches

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: <Pine.LNX.4.64.0703020942550.17017@schroedinger.engr.sgi.com>
Date:	Fri, 2 Mar 2007 09:48:17 -0800 (PST)
From:	Christoph Lameter <clameter@...r.sgi.com>
To:	Mel Gorman <mel@...net.ie>
cc:	Andrew Morton <akpm@...ux-foundation.org>, npiggin@...e.de,
	mingo@...e.hu, jschopp@...tin.ibm.com, arjan@...radead.org,
	torvalds@...ux-foundation.org, mbligh@...igh.org,
	kamezawa.hiroyu@...fujitsu.com, linux-kernel@...r.kernel.org
Subject: Re: The performance and behaviour of the anti-fragmentation related
 patches

On Fri, 2 Mar 2007, Mel Gorman wrote:

> > I still think that the list based approach is sufficient for memory 
> > hotplug if one restricts  the location of the unmovable MAX_ORDER chunks 
> > to not overlap the memory area where we would like to be able to remove 
> > memory.
> 
> Yes, true. In the part where I bias placements of unmovable pages at
> lower PFNs, additional steps would need to be taken. Specifically, the
> lowest block MAX_ORDER_NR_PAGES used for movable pages would need to be
> reclaimed for unmovable allocations.

I think sparsemem can provide some memory maps that show where there are 
section of memory that are hot pluggable. So the MAX_ORDER blocks need
to be categorized as to whether they are in such a section or not. If you 
need another MAX_ORDER block for an unmovable type of allocation then make 
sure that it is not marked as hotpluggable by sparsemem. If we are in an 
emergency situation were we must use a MAX_ORDER block that is currently 
hotpluggable for unmovable allocations then we need to trigger something 
in sparsmem that disabled hotplug for that memory section.

> It's simply more complex. I believe it's doable. The main plus going for
> the zone is that it is a clearly understood concept and it gives hard
> guarantees.

And it gives the sysadmin headaches and increases management VM management 
overhead because we now have more bits in the page struct that tell us 
about the zone that the page belongs to. Another distinction to worry 
about in the VM. If the limit is set too high then we have memory that is 
actually movable but since its on the wrong side of the limit we cannot 
use it. If the limit is set too low then the systewm will crash.

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