linux-kernel - Re: [PATCH] Bias the location of pages freed for min_free_kbytes in the same MAX_ORDER_NR

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:	Sun, 18 Mar 2007 10:12:59 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Mariusz Kozlowski <m.kozlowski@...land.pl>,
	Andy Whitcroft <apw@...dowen.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Bias the location of pages freed for min_free_kbytes in
 the same MAX_ORDER_NR_PAGES blocks

On Sun, 18 Mar 2007 11:35:36 +0000 (GMT) Mel Gorman <mel@....ul.ie> wrote:

> > But let me leap ahead of myself.
> >
> >> CONFIG_PAGE_GROUP_BY_MOBILITY
> >
> > Why does this config item exist?  It's not good to have some mysterious
> > knob which affects mm behaviour at compile time.  We need to make up our
> > minds and stick with it.
> >
> 
> The configuration item exists because there were concerns over the memory 
> footprint and cache line footprint. It was introduced to address that 
> concern and also so that it would be possible to compare the performance 
> behavior of anti-fragmentation. Your comment rang a bell though so I 
> searched the archives to see this comment from Andi Kleen;
> 
> ===
> If anything this should be a boot time option or perhaps sysctl, not a 
> config. In general CONFIGs that change runtime behaviour are evil - just 
> makes changing the option more painful, causes problems for distribution 
> users, doesn't make much sense, etc.etc.
> 
> Also #ifdef as a documentation device is a really really scary concept.
> Yuck.
> ===
> 
> A sysctl would avoid any cache line footprint but not the memory overhead 
> because the freelists in struct zone as those freelists would still exist. 
> I could make the option depend on CONFIG_EMBEDDED for the zone overhead. 
> Would that make sense or would it be preferable to ditch the option 
> altogether?
> 
> I'll start looking at doing a sysctl so it can be disabled at runtime if 
> necessary. I strongly suspect that it cannot be enabled again once 
> disabled but I don't see that as a problem as such.

How much additional memory consumption are we expecting here?

Whether it's runtime or compile-time, the optionality is not good.
-
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/