linux-kernel - Re: [PATCH] Apply memory policies to top two highest zones when highest zone is ZONE

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:	Tue, 7 Aug 2007 17:55:47 +0100
From:	mel@...net.ie (Mel Gorman)
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Andi Kleen <ak@...e.de>, Lee.Schermerhorn@...com, clameter@....com,
	kamezawa.hiroyu@...fujitsu.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Apply memory policies to top two highest zones when highest zone is ZONE_MOVABLE

On (06/08/07 22:12), Andrew Morton didst pronounce:
> On Mon, 6 Aug 2007 22:55:41 +0100 mel@...net.ie (Mel Gorman) wrote:
> 
> > On (06/08/07 22:31), Andi Kleen didst pronounce:
> > > 
> > > > If correct, I would suggest merging the horrible hack for .23 then taking
> > > > it out when we merge "grouping pages by mobility".  But what if we don't do
> > > > that merge?
> > > 
> > > Or disable ZONE_MOVABLE until it is usable?
> > 
> > It's usable now. The issue with policies only occurs if the user specifies
> > kernelcore= or movablecore= on the command-line. Your language suggests
> > that you believe policies are not applied when ZONE_MOVABLE is configured
> > at build-time.
> 
> So..  the problem which we're fixing here is only present when someone
> use kernelcore=.  This is in fact an argument for _not_ merging the
> horrible-hack.
> 

It's even more constrained than that. It only applies to the MPOL_BIND
policy when kernelcore= is specified. The other policies work the same
as they ever did.

> How commonly do we expect people to specify kernelcore=?  If "not much" then
> it isn't worth adding the __alloc_pages() overhead?
> 

For 2.6.23 at least, it'll be "not much". While I'm not keen on leaving
MPOL_BIND as it is for 2.6.23, we can postpone the final decision until
we've bashed the one-zonelist-per-node patches a bit and see do we want to
do that instead.

> (It's a pretty darn small overhead, I must say)

And it's simplier than the one-zone-list-per-node patches. The
current draft of the patch I'm working on looks something like;

 arch/parisc/mm/init.c     |   10 ++-
 drivers/char/sysrq.c      |    2 
 fs/buffer.c               |    2 
 include/linux/gfp.h       |    3 -
 include/linux/mempolicy.h |    2 
 include/linux/mmzone.h    |   42 +++++++++++++++
 include/linux/swap.h      |    2 
 mm/mempolicy.c            |    6 +-
 mm/mmzone.c               |   28 ++++++++++
 mm/oom_kill.c             |    8 +--
 mm/page_alloc.c           |  122 +++++++++++++++++++++-------------------------
 mm/slab.c                 |   11 ++--
 mm/slub.c                 |   11 ++--
 mm/vmscan.c               |   16 +++---
 14 files changed, 164 insertions(+), 101 deletions(-)

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