linux-kernel - Re: [PATCHv4 0/3] new APIs to allocate buffer-cache with user specific flag

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: <20140904151612.7bf5b813069ff78973e01571@linux-foundation.org>
Date:	Thu, 4 Sep 2014 15:16:12 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Gioh Kim <gioh.kim@....com>
Cc:	jack@...e.cz, tytso@....edu, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, paulmck@...ux.vnet.ibm.com,
	peterz@...radead.org, adilger.kernel@...ger.ca, minchan@...nel.org,
	js1304@...il.com, gunho.lee@....com
Subject: Re: [PATCHv4 0/3] new APIs to allocate buffer-cache with user
 specific flag

On Thu,  4 Sep 2014 16:29:38 +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 new APIs that allocates page cache with specific flag passed by an
> argument.
> *_gfp APIs are for user want to set page allocation flag for page cache
> allocation.
> And *_unmovable APIs are for the user wants to allocate page cache from
> non-movable area.
> 
> It is useful for ext4/ext3 and others that want to hold page cache for a long
> time.

Could we please have some detailed information about the real-world
effect of this patchset?

You earlier said "My test platform is currently selling item in the
market.  And also I test my patch when my platform is working as if
real user uses it.".

But what were the problems which were observed in standard kernels and
what effect did this patchset have upon them?  Some quantitative
measurements will really help here.

I'm trying to get an understanding of how effective and important the
change is, whether others will see similar benefits.  I'd also like to
understand how *complete* the fix is - were the problems which you
observed completely fixed, or do outstanding problems remain?

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