Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753748Ab1DOTi5 (ORCPT ); Fri, 15 Apr 2011 15:38:57 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:24649 "EHLO rcsinet10.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751347Ab1DOTiz convert rfc822-to-8bit (ORCPT ); Fri, 15 Apr 2011 15:38:55 -0400 MIME-Version: 1.0 Message-ID: <67d72d8f-9809-4e43-9e90-417d4eb14db1@default> Date: Fri, 15 Apr 2011 12:37:11 -0700 (PDT) From: Dan Magenheimer To: OGAWA Hirofumi Cc: Chris Mason , viro@zeniv.linux.org.uk, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, mfasheh@suse.com, jlbec@evilplan.org, matthew@wil.cx, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, ocfs2-devel@oss.oracle.com, linux-mm@kvack.org, hch@infradead.org, ngupta@vflare.org, jeremy@goop.org, JBeulich@novell.com, Kurt Hackel , npiggin@kernel.dk, Dave Mccracken , riel@redhat.com, avi@redhat.com, Konrad Wilk , mel@csn.ul.ie, yinghan@google.com, gthelen@google.com, torvalds@linux-foundation.org Subject: RE: [PATCH V8 1/8] mm/fs: cleancache documentation References: <20110414211601.GA27691@ca-server1.us.oracle.com 87mxjr4a6o.fsf@devron.myhome.or.jp> In-Reply-To: <87mxjr4a6o.fsf@devron.myhome.or.jp> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.4.1.0 (410211) [OL 12.0.6550.5003] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4DA89E78.0152:SCFSTAT5015188,ss=1,fgs=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1832 Lines: 42 Hi Hirofumi-san -- > Another question: why can't this enable/disable per sb, e.g. via mount > options? (I have the interest the cache stuff like this by SSD on > physical systems like dragonfly's swapcache.) This would be useful and could be added later if individual filesystems choose to add the mount functionality. My goal with this patchset is to enable only minimal functionality so that other kernel developers can build on it. > Well, anyway, I guess force enabling this for mostly unused sb can just > add cache-write overhead and call for unpleasing reclaim to backend > (because of limited space of backend) like updatedb. If the sb is mostly unused, there should be few puts. But you are correct that if the backend has only very limited space, cleancache adds cost and has little value. On these systems, cleancache should probably be disabled. However, the cost is very small so leaving it enabled may not even show a measureable performance impact. > And already there is in FAQ though, I also have interest about async > interface because of SDD backend (I'm not sure for now though). Is > there any plan like SSD backend? Yes, I think an SSD backend is very interesting, especially if the SSD is "very near" to the processor so that it can be used as a RAM extension rather than as an I/O device. The existing cleancache hooks will work for this and I am working on a cleancache backend called RAMster that will be a good foundation to access other asynchronous devices. See: http://marc.info/?l=linux-mm&m=130013567810410&w=2 Thanks for your feedback! Dan -- 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/