From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 6A6107F47 for ; Tue, 1 Sep 2015 02:41:07 -0500 (CDT) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id EA9B5AC004 for ; Tue, 1 Sep 2015 00:41:06 -0700 (PDT) Received: from bombadil.infradead.org ([198.137.202.9]) by cuda.sgi.com with ESMTP id Hu4H50NbfzKQXpaI (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 01 Sep 2015 00:41:05 -0700 (PDT) Date: Tue, 1 Sep 2015 00:41:03 -0700 From: Christoph Hellwig Subject: Re: [PATCH 2/4] xfs: Introduce writeback context for writepages Message-ID: <20150901074103.GA27231@infradead.org> References: <1440479153-1584-1-git-send-email-david@fromorbit.com> <1440479153-1584-3-git-send-email-david@fromorbit.com> <20150831180221.GA16371@bfoster.bfoster> <20150831185612.GB349@infradead.org> <20150831221743.GI26895@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150831221743.GI26895@dastard> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Dave Chinner Cc: Christoph Hellwig , Brian Foster , xfs@oss.sgi.com On Tue, Sep 01, 2015 at 08:17:43AM +1000, Dave Chinner wrote: > The patch changes the bio allocation patterns - it allocates them on > the fly and holds them, so we could potentially exhaust the bio > mempool with this submission technique. I've spend time to look over the patch again, and still don't see a change. Both in the old and new code we walk over the ioends and build bios on the fly in xfs_submit_ioend(), which is always called near then end of the writeback code; at the end of xfs_vm_writepage in the old version, and from the end of xfs_vm_writepage/xfs_vm_writepages through xfs_writepage_submit in the new code (not taking the error case into account, which probably should moe there, too). The only big difference is.. > The ioend allocation pattern > is different, too, because we only used to have 1 per buffer on a > writepage call and the last one was used for the write clustering. .. that we now build up way bigger ioend chains. So back to Brians concern: we can now have fairly large piles of ioends built up while potentially getting scheduled out, and this does look like a potential real issue to me. I wonder if we should (ab-)use the blk_plug_cb infrastructure so that we can flush the pending ioends out on a context switch? _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs