linux-ext4 - Re: [PATCH 0/2] new API to allocate buffer-cache for superblock in non-movable area

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: <20140801152459.GA7525@quack.suse.cz>
Date:	Fri, 1 Aug 2014 17:24:59 +0200
From:	Jan Kara <jack@...e.cz>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Jan Kara <jack@...e.cz>, Gioh Kim <gioh.kim@....com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4@...r.kernel.org, linux-mm@...ck.org,
	Minchan Kim <minchan@...nel.org>,
	Joonsoo Kim <js1304@...il.com>
Subject: Re: [PATCH 0/2] new API to allocate buffer-cache for superblock in
 non-movable area

On Fri 01-08-14 15:36:18, Peter Zijlstra wrote:
> On Fri, Aug 01, 2014 at 11:57:00AM +0200, Jan Kara wrote:
> > So the quiestion really is how hard guarantee do you need that a page in
> > movable zone is really movable. Or better in what timeframe should it be
> > movable? It may be possible to make e.g. migratepage callback for ext4
> > blkdev pages which will handle migration of pages that are just idly
> > sitting in a journal waiting to be committed. That may be reasonably doable
> > although it won't be perfect. Or we may just decide it's not worth the
> > bother and allocate all blkdev pages from unmovable zone...
> 
> So the point of CMA is to cater to those (arguably broken) devices that
> do not have scatter gather IO, and these include things like the camera
> device on your phone.
> 
> Previously (and possibly currently) your android Linux kernel will
> simply preallocate a massive physically linear chunk of memory and
> assign it to the camera hardware and not use it at all.
> 
> This is a terrible waste for most of the time people aren't running
> their camera app at all. So the point is to allow usage of the memory,
> but upon request be able to 'immediately' clear it through
> migration/writeback.
> 
> So we should be fairly 'quick' in making the memory available,
> definitely sub second timeframes.
  OK, makes sense. But then if there's heavy IO going on, anything that has
IO pending on it is pinned and IO completion can easily take something
close to a second or more. So meeting subsecond deadlines may be tough even
for ordinary data pages under heavy load, even more so for metadata where
there are further constraints. OTOH phones aren't usually IO bound so in
practice it needn't be so bad ;). So if it is sub-second unless someone
loads the storage, then that sounds doable even for metadata. But we'll
need to attach ->migratepage callback to blkdev pages and at least in ext4
case teach it how to move pages tracked by the journal.
 
> Sadly its not only mobile devices that excel in crappy hardware, there's
> plenty desktop stuff that could use this too, like some of the v4l
> devices iirc.
  Yeah, but in such usecases the guarantees we can offer for completion of
migration are even more vague :(.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html