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: <20140814142610.6f0d4194c373fef188870772@linux-foundation.org>
Date:	Thu, 14 Aug 2014 14:26:10 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Gioh Kim <gioh.kim@....com>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>, Jan Kara <jack@...e.cz>,
	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, Minchan Kim <minchan@...nel.org>,
	Joonsoo Kim <js1304@...il.com>,
	이건호 
	<gunho.lee@....com>
Subject: Re: [PATCH 0/2] new APIs to allocate buffer-cache for superblock in
 non-movable area

On Thu, 14 Aug 2014 14:12:17 +0900 Gioh Kim <gioh.kim@....com> wrote:

> This patch try to solve problem that a long-lasting page caches of
> ext4 superblock and journaling of superblock disturb page migration.
> 
> I've been testing CMA feature on my ARM-based platform
> and found that two page caches cannot be migrated.
> They are page caches of superblock of ext4 filesystem and its journaling data.
> 
> Current ext4 reads superblock with sb_bread() that allocates page
> from movable area. But the problem is that ext4 hold the page until
> it is unmounted. If root filesystem is ext4 the page cannot be migrated forever.
> And also the journaling data for the superblock cannot be migreated.
> 
> I introduce a new API for allocating page cache from non-movable area.
> It is useful for ext4/ext3 and others that want to hold page cache for a long time.

All seems reasonable to me.  The additional overhead in buffer.c from
additional function arguments is regrettable but I don't see a
non-hacky alternative.


One vital question which the changelog doesn't really address (it
should): how important is this patch?  Is your test system presently
"completely dead in the water utterly unusable" or "occasionally not
quite as good as it could be".  Somewhere in between?

See, the patch adds costs.  I'd like us to have a good understanding of
what benefits it brings.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ