linux-kernel - Re: [PATCH -v2 -mm] add extra free kbytes tunable

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: <alpine.DEB.2.00.1109011501260.22550@chino.kir.corp.google.com>
Date:	Thu, 1 Sep 2011 15:08:00 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Rik van Riel <riel@...hat.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	Satoru Moriya <smoriya@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	lwoodman@...hat.com, Seiji Aguchi <saguchi@...hat.com>,
	hughd@...gle.com, hannes@...xchg.org
Subject: Re: [PATCH -v2 -mm] add extra free kbytes tunable

On Thu, 1 Sep 2011, Andrew Morton wrote:

> > Add a userspace visible knob
> 
> argh.  Fear and hostility at new knobs which need to be maintained for
> ever, even if the underlying implementation changes.
> 

Do we really need to maintain tunables that lose their purpose either 
because the implementation changes or is patched to fix the issue that the 
tunable was intended to address without requiring it?

Are there really userspace tools written to not be able to handle -ENOENT 
when one of these gets removed?

> > It may also be useful to reduce the memory use of virtual
> > machines (temporarily?), in a way that does not cause memory
> > fragmentation like ballooning does.
> 
> Maybe.  You need to alter the setting, then somehow persuade all the
> targeted kswapd's to start running, then somehow determine that they've
> done their thing, then unalter the /proc setting.  Not the best API
> we've ever designed ;)
> 

And, unfortunately, this could have negative effects if using cpusets 
and/or mempolicies since this is global across all zones such that jobs 
that do not require such "extra" memory would be unfairly penalized with 
work incurred by additional reclaim they don't need.  And if the job is 
constrained to a memory cgroup, there's no guarantee it will reclaim back 
to these altered watermarks.
--
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/