From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754146Ab1HSLyC (ORCPT ); Fri, 19 Aug 2011 07:54:02 -0400 Received: from mail-iy0-f170.google.com ([209.85.210.170]:61311 "EHLO mail-iy0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753096Ab1HSLyA (ORCPT ); Fri, 19 Aug 2011 07:54:00 -0400 Subject: Re: [PATCH] writeback: Per-block device bdi->dirty_writeback_interval and bdi->dirty_expire_interval. From: Artem Bityutskiy Reply-To: dedekind1@gmail.com To: Wu Fengguang Cc: Kautuk Consul , Mel Gorman , KOSAKI Motohiro , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , Jan Kara , Dave Chinner , Greg Thelen Date: Fri, 19 Aug 2011 14:55:43 +0300 In-Reply-To: <20110818131343.GA17473@localhost> References: <20110818094824.GA25752@localhost> <1313669702.6607.24.camel@sauron> <20110818131343.GA17473@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2 (3.0.2-3.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1313754949.6607.52.camel@sauron> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2011-08-18 at 21:13 +0800, Wu Fengguang wrote: > Thinking twice about it, I find that the different requirements for > interval flash/external microSD can also be solved by this scheme. > > Introduce a per-bdi dirty_background_time (and optionally dirty_time) > as the counterpart of (and works in parallel to) global dirty[_background]_ratio, > however with unit "milliseconds worth of data". > > The per-bdi dirty_background_time will be set low for external microSD > and high for internal flash. Then you get timely writeouts for microSD > and reasonably delayed writes for internal flash (controllable by the > global dirty_expire_centisecs). > > The dirty_background_time will actually work more reliable than > dirty_expire_centisecs because it will checked immediately after the > application dirties more pages. And the dirty_time could provide > strong data integrity guarantee -- much stronger than > dirty_expire_centisecs -- if used. > > Does that sound reasonable? Yes, this would probably work. But note, we do not have this problem anymore, I was just talking about the past experience, so I cannot validate any possible patch. Thanks. -- Best Regards, Artem Bityutskiy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Artem Bityutskiy Subject: Re: [PATCH] writeback: Per-block device bdi->dirty_writeback_interval and bdi->dirty_expire_interval. Date: Fri, 19 Aug 2011 14:55:43 +0300 Message-ID: <1313754949.6607.52.camel@sauron> References: <20110818094824.GA25752@localhost> <1313669702.6607.24.camel@sauron> <20110818131343.GA17473@localhost> Reply-To: dedekind1@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Kautuk Consul , Mel Gorman , KOSAKI Motohiro , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , Jan Kara , Dave Chinner , Greg Thelen To: Wu Fengguang Return-path: In-Reply-To: <20110818131343.GA17473@localhost> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2011-08-18 at 21:13 +0800, Wu Fengguang wrote: > Thinking twice about it, I find that the different requirements for > interval flash/external microSD can also be solved by this scheme. > > Introduce a per-bdi dirty_background_time (and optionally dirty_time) > as the counterpart of (and works in parallel to) global dirty[_background]_ratio, > however with unit "milliseconds worth of data". > > The per-bdi dirty_background_time will be set low for external microSD > and high for internal flash. Then you get timely writeouts for microSD > and reasonably delayed writes for internal flash (controllable by the > global dirty_expire_centisecs). > > The dirty_background_time will actually work more reliable than > dirty_expire_centisecs because it will checked immediately after the > application dirties more pages. And the dirty_time could provide > strong data integrity guarantee -- much stronger than > dirty_expire_centisecs -- if used. > > Does that sound reasonable? Yes, this would probably work. But note, we do not have this problem anymore, I was just talking about the past experience, so I cannot validate any possible patch. Thanks. -- Best Regards, Artem Bityutskiy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org