Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751282AbbEYT4B (ORCPT <rfc822;w@1wt.eu>);
	Mon, 25 May 2015 15:56:01 -0400
Received: from imap.thunk.org ([74.207.234.97]:56677 "EHLO imap.thunk.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750791AbbEYTz5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 May 2015 15:55:57 -0400
Date: Mon, 25 May 2015 15:55:51 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/3] f2fs crypto: use bounce pages from mempool first
Message-ID: <20150525195551.GB16402@thunk.org>
Mail-Followup-To: Theodore Ts'o <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
References: <1432255225-76792-1-git-send-email-jaegeuk@kernel.org>
 <1432255225-76792-2-git-send-email-jaegeuk@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1432255225-76792-2-git-send-email-jaegeuk@kernel.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1706
Lines: 35

On Thu, May 21, 2015 at 05:40:24PM -0700, Jaegeuk Kim wrote:
> If a lot of write streams are triggered, alloc_page and __free_page are
> costly called, resulting in high memory pressure.
> 
> In order to avoid that, let's reuse mempool pages for writeback pages.

The reason why the mempool pages was used as a fallback was because
once we are deep in the writeback code, handling memory allocation
failures is close to impossible, since we've already made enough
changes that unwinding them would be extremely difficult.  So the
basic idea was to use the mempool as an emergency reserve, since
Failure Is Not An Option, and the alternative, which is to simply loop
until the mm subsystem sees fit to give us a page, has sometimes led
to deadlock.

The primary source of write streams should be either (a) fsync
operations, or (b) calls from the writeback thread.  Are there any
additional sources for f2fs?  If they are calls from fsync operations,
and we have more than a threshold number of write operations in play,
we might want to think about blocking the fsync/fdatasync writeback,
**before** the operation starts taking locks, so other write
operations can proceed.  And the writeback thread should keep the
number of write operations to a reasonable number, especially given
that we are treating page encryption as a blocking operation.  Or is
there something else going on which is making this to be more of a
problem for f2fs?

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/