From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754498AbaE3B7h (ORCPT ); Thu, 29 May 2014 21:59:37 -0400 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:51722 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751538AbaE3B7g (ORCPT ); Thu, 29 May 2014 21:59:36 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar1ZAIHlh1N5LL1sPGdsb2JhbABZgweDRIUIonABAQEBAQEGmBgBgQYXAwEBAQE4NYIlAQEFOhwjEAgDGAklDwUlAwcaExuIJtdjFxaFP4h9B4RABJl0ixqLWis Date: Fri, 30 May 2014 11:58:52 +1000 From: Dave Chinner To: Linus Torvalds Cc: Minchan Kim , Linux Kernel Mailing List , Andrew Morton , linux-mm , "H. Peter Anvin" , Ingo Molnar , Peter Zijlstra , Mel Gorman , Rik van Riel , Johannes Weiner , Hugh Dickins , Rusty Russell , "Michael S. Tsirkin" , Dave Hansen , Steven Rostedt Subject: Re: [RFC 2/2] x86_64: expand kernel stack to 16K Message-ID: <20140530015852.GG14410@dastard> References: <20140528223142.GO8554@dastard> <20140529013007.GF6677@dastard> <20140529015830.GG6677@dastard> <20140529233638.GJ10092@bbox> <20140530002021.GM10092@bbox> <20140530005042.GO10092@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 29, 2014 at 06:24:02PM -0700, Linus Torvalds wrote: > On Thu, May 29, 2014 at 5:50 PM, Minchan Kim wrote: > >> > >> You could also try Dave's patch, and _not_ do my mm/vmscan.c part. > > > > Sure. While I write this, Rusty's test was crached so I will try Dave's patch, > > them yours except vmscan.c part. > > Looking more at Dave's patch (well, description), I don't think there > is any way in hell we can ever apply it. If I read it right, it will > cause all IO that overflows the max request count to go through the > scheduler to get it flushed. Maybe I misread it, but that's definitely > not acceptable. Maybe it's not noticeable with a slow rotational > device, but modern ssd hardware? No way. > > I'd *much* rather slow down the swap side. Not "real IO". So I think > my mm/vmscan.c patch is preferable (but yes, it might require some > work to make kswapd do better). > > So you can try Dave's patch just to see what it does for stack depth, > but other than that it looks unacceptable unless I misread things. Yeah, it's a hack, not intended as a potential solution. I'm thinking, though, that plug flushing behaviour is actually dependent on plugger context and there is no one "correct" behaviour. If we are doing process driven IO, then we want to do immediate dispatch, but for IO where stack is an issue or is for bulk throughput (e.g. background writeback) async dispatch through kblockd is desirable. If the patch I sent solves the swap stack usage issue, then perhaps we should look towards adding "blk_plug_start_async()" to pass such hints to the plug flushing. I'd want to use the same behaviour in __xfs_buf_delwri_submit() for bulk metadata writeback in XFS, and probably also in mpage_writepages() for bulk data writeback in WB_SYNC_NONE context.... Cheers, Dave. -- Dave Chinner david@fromorbit.com