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]
Date:	Mon, 4 Dec 2006 13:43:44 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...l.org>
cc:	Mel Gorman <mel@...net.ie>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Add __GFP_MOVABLE for callers to flag allocations that
 may be migrated

On Mon, 4 Dec 2006, Andrew Morton wrote:

> What happens when we need to run reclaim against just a section of a zone?
> Lumpy-reclaim could be used here; perhaps that's Mel's approach too?

Why would we run reclaim against a section of a zone?
 
> We'd need new infrastructure to perform the
> section-of-a-zone<->physical-memory-block mapping, and to track various
> states of the section-of-a-zone.  This will be complex, and buggy.  It will
> probably require the introduction of some sort of "sub-zone" structure.  At
> which stage people would be justified in asking "why didn't you just use
> zones - that's what they're for?"

Mel aready has that for anti-frag. The sections are per MAX_ORDER area 
and the only states are movable unmovable and reclaimable. There is 
nothing more to it. No other state information should be added. Why would 
we need sub zones? For what purpose?

> > Then we should be doing some work to cut down the number of unmovable 
> > allocations.
> 
> That's rather pointless.  A feature is either reliable or it is not.  We'll
> never be able to make all kernel allocations reclaimable/moveable so we'll
> never be reliable with this approach.  I don't see any alternative to the
> never-allocate-kernel-objects-in-removeable-memory approach.  

What feature are you talking about?

Why would all allocations need to be movable when we have a portion for 
unmovable allocations?
-
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/

Powered by blists - more mailing lists