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.0703021750490.16858@skynet.skynet.ie>
Date:	Fri, 2 Mar 2007 17:59:30 +0000 (GMT)
From:	Mel Gorman <mel@....ul.ie>
To:	Christoph Lameter <clameter@...r.sgi.com>
Cc:	Mel Gorman <mel@...net.ie>,
	Andrew Morton <akpm@...ux-foundation.org>, npiggin@...e.de,
	mingo@...e.hu, Joel Schopp <jschopp@...tin.ibm.com>,
	arjan@...radead.org, torvalds@...ux-foundation.org,
	mbligh@...igh.org, kamezawa.hiroyu@...fujitsu.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: The performance and behaviour of the anti-fragmentation related
 patches

On Fri, 2 Mar 2007, Christoph Lameter wrote:

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

That makes the problem slightly easier. If sparsemem sections are aware of 
whether they are hotpluggable or not, __rmqueue_fallback() (from the 
list-based anti-frag patches) can be taught to never use those sections 
for unmovable allocations.

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

Which should be doable.

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

I'm aware of this. It believe it could all be done in the context of 
list-based - just that it requires more code. Zones are easier to 
understand for most people and their behavior is better understood. If a 
workload is discovered that list-based doesn't handle, the zone can be 
used until the problem is solved.

This is why the anti-fragmentation and zone-based approaches are no longer 
mutually exclusive as they were in earlier versions.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
-
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/