linux-kernel - Re: [PATCH v10 00/16] Volatile Ranges v10

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>] [day] [month] [year] [list]

Message-ID: <20140203183614.GL6963@cmpxchg.org>
Date:	Mon, 3 Feb 2014 13:36:14 -0500
From:	Johannes Weiner <hannes@...xchg.org>
To:	Jan Kara <jack@...e.cz>
Cc:	Minchan Kim <minchan@...nel.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>, Hugh Dickins <hughd@...gle.com>,
	Dave Hansen <dave.hansen@...el.com>,
	Rik van Riel <riel@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Michel Lespinasse <walken@...gle.com>,
	John Stultz <john.stultz@...aro.org>,
	Dhaval Giani <dhaval.giani@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Android Kernel Team <kernel-team@...roid.com>,
	Robert Love <rlove@...gle.com>, Mel Gorman <mel@....ul.ie>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Dave Chinner <david@...morbit.com>, Neil Brown <neilb@...e.de>,
	Andrea Righi <andrea@...terlinux.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Mike Hommey <mh@...ndium.org>, Taras Glek <tglek@...illa.com>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Rob Clark <robdclark@...il.com>, Jason Evans <je@...com>
Subject: Re: [PATCH v10 00/16] Volatile Ranges v10

On Mon, Feb 03, 2014 at 03:58:06PM +0100, Jan Kara wrote:
> On Fri 31-01-14 11:49:01, Johannes Weiner wrote:
> > On Wed, Jan 29, 2014 at 02:11:02PM +0900, Minchan Kim wrote:
> > > >    The only way to make these semantics clean is either
> > > > 
> > > >      a) have vrange() return a range ID so that only full ranges can
> > > >      later be marked non-volatile, or
> > > 
> > > > 
> > > >      b) remember individual page purges so that sub-range changes can
> > > >      properly report them
> > > > 
> > > >    I don't like a) much because it's somewhat arbitrarily more
> > > >    restrictive than madvise, mprotect, mmap/munmap etc.  And for b),
> > > >    the straight-forward solution would be to put purge-cookies into
> > > >    the page tables to properly report purges in subrange changes, but
> > > >    that would be even more coordination between vmas, page tables, and
> > > >    the ad-hoc vranges.
> > > 
> > > Agree but I don't want to put a accuracy of defalut vrange syscall.
> > > Page table lookup needs mmap_sem and O(N) cost so I'm afraid it would
> > > make userland folks hesitant using this system call.
> > 
> > If userspace sees nothing but cost in this system call, nothing but a
> > voluntary donation for the common good of the system, then it does not
> > matter how cheap this is, nobody will use it.  Why would they?  Even
>   I think this is a flawed logic. If you take it to the extreme then why
> each application doesn't allocate all the available memory and never free
> it? Because users will kick such application in the ass as soon as they
> have a viable alternative. So there is certainly a relatively strong
> benefit in being a good citizen on the system. But it's a matter of a
> tradeoff - if being a good citizen costs you too much (in the extreme if it
> would make the application hardly usable because it is too slow), then you
> just give up or hack it around in some other way...

Oh, that is exactly what I was trying to point out.  The argument was
basically that it has to be as cheap and lightweight as humanly
possible because applications participate voluntarily and they won't
donate memory back if it comes at a cost.

And as you said, this is flawed.  There is an incentive to give back
memory other than altruistic tendencies, namely the looming kick in
the butt.

So I very much agree that there is a trade-off to be had, but I think
the cost of the proposed implementation is not justified.

If we agree that simply not returning memory is unacceptable anyway,
providing an interface that is drastically cheaper than the current
means of returning memory is already an improvement.  Even if it's
still O(#pages).  So I think the incentive to use it is there.  We
should design it to fit into the existing VM and then optimize it,
rather than design for an (unnecessary) optimization.
--
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/