From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934531AbbI1QpJ (ORCPT ); Mon, 28 Sep 2015 12:45:09 -0400 Received: from mout.perfora.net ([74.208.4.196]:58588 "EHLO mout.perfora.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933867AbbI1QpE (ORCPT ); Mon, 28 Sep 2015 12:45:04 -0400 Subject: Re: [PATCH] Patch to integrate RapidDisk and RapidCache RAM Drive / Caching modules into the kernel To: Christoph Hellwig References: <1443374244.8013.7.camel@petros-ultrathin> <20150928064936.GA22280@infradead.org> <20150928162944.GA29562@infradead.org> Cc: linux-kernel@vger.kernel.org, "devel@rapiddisk.org" From: Petros Koutoupis Message-ID: <56096E90.2020000@petroskoutoupis.com> Date: Mon, 28 Sep 2015 11:45:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150928162944.GA29562@infradead.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0B8S13vpuOe5LdkwDeTZ2jmnej/2KHpq3pkEIECdnYj58QMTQAy bs1z2bAukgrqW3fx1tWoIFkorOI/5IeHYztr5B03Wyhav5yI0eFbN0haKcAQ5GZZYt2LN+s yMXuaaPoSJJ5PAr3E1Yh6N37DtAz1WrlpSIoX/UEtO/6ILlDYaDAIv7p556I4vCjPjymShM 8Usq+dXheSJEy/bSkv0/w== X-UI-Out-Filterresults: notjunk:1;V01:K0:iOdYG6b8bNw=:Lz5Bmj2uHAv3wYSLp0Z6on rolxKbrFco3Lotb05A7gJuSQCtGbygkEjBcCdHHOsx0iSpe24FrBR1nb74rAdpyCLG4nxsVQ2 ZFqywWFXM608z727xDWXSt91VgNilRRjRDviO6ZLaXvdeUIl6oabmkImNxsmLAJljIIf2F4gW tPgUNDEMSGKDhWN9qN050lhmteOOhhBsoAkMNoOksjTTjLuzFVgbcjkCb1LfGmvLmhiqrrUi8 uHREBZrjS9iq4j40z+XZgXxCaRD9D8APZcXaEB/fq3XafRwzpv6au67Sp3rcYpRP3dO2JpT6z U8ginIxiFvrcCz2EFvGS1qI8wfCfHElFZ9TEEXjnQwySIpzDLS9lVMmRk2CFfOq4ZjnPxBcSE UA1jfn9lrnmL9f8B6rFwv8chU6vnTDnQGKiAKbqATfEb7TKtgLs2RqI7uaq9yEp+kyUgQ/Erv 0aGqPsd8m8MpRk8aRRHd2wAF/+QFnokR7Tq7Krf0ooDNZ7kcdQGJJM5swv+0jWltzkLm/eNDv J1Czo+xjLbHsOu4bJ0YV+8bmXSw2grLLf1U5WsRYc6xU9ODgZB1EfeVyM8u71FF9MKIPxpRZo NOfMt0jXozdJMZQbPXy6UrGI2yyUDj2HhGHew87Kdg/jdOhSmoQEClb1BNJTNGwohwJ1woFGx DNZMAhuDmpEd42yC6nAeBEe6UKm6SPX2NETvS/TCEe3wjXxVPO/Mx8SE0NeAQUMqWveIvLTNY JBYkUbGBuShTT9ZE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph, See my replies below.... On 9/28/15 11:29 AM, Christoph Hellwig wrote: > Hi Petros, > > On Mon, Sep 28, 2015 at 09:12:13AM -0500, Petros Koutoupis wrote: >> 1. Unlike the already mainline ramdisk driver, RapidDisk is designed to be >> managed dynamically. That is, instead of configuring a fixed number of >> volumes and volume sizes as compile/boot time variables, RapidDisk will >> allow you to add, remove, and resize your RAM drive(s) at runtime. Besides, >> the built in module is designed to work with smaller sizes in mind while >> RapidDisk focuses on larger sizes that can reach to the multiple Gigabytes >> or even Terabytes. Much like the built in module, it will allocate pages as >> they are needed which allows for over provisioning (not that it is advised) >> of volume sizes. > The ramdisk driver allows to selects sizes and count at module load > load. I agree that having runtime control would be even better, but > that's best done by adding a runtime interface to the existing driver > instead of duplicating it. I understand the concern and I will definitely scope out this approach, although at the moment, I am not sure how both approaches will play nice together. As mentioned above, the current implementation requires the predefined number of ram drives with the specified size to be configured at boot time (or compiled into the kernel). The only wiggle room I see for runtime control is resizing individual volumes. >> 2. The majority of RapidDisk code focuses on the use of Volatile memory. >> The support for Non-Volatile memory is a bit newer and there may be some >> overlap here with the recently integrated pmem code. The only advantage to >> having this code within RapidDisk is to provide the user with the ability >> to manage both technologies simultaneously, through a single interface. > Which really doesn't sound like a good enough reason to duplicate it. I do not disagree with your comment here. This component does not have to be patched into the mainline. >> 3. The RapidCache component is designed around the Non-Volatile >> functionality of RapidDisk (hence the block-level Write-Through caching). >> It is also coded and optimized around the RapidDisk sizes/variables, >> out-of-box. It is worth noting that I am in the process of expanding this >> module to add deduplication support. This will leverage RapidDisk's ability >> to allocate pages only when needed and reduce the cache's memory footprint; >> making more out of less. > Still needs some code comparism to our existing two caching solutions. > > I'd love to see you go ahead with the dynamic ramdisk configuration as > this is clearly a very useful feature. A caching solution that is > optimized for non-volatile memory does sound useful, but we'll still > need a patch better explaining how it actually is as useful as it might > sound. CORRECTION: I meant to say Volatile and NOT Non-Volatile. RapidCache is designed around Volatile memory. I guess I was a little to excited in my response and I do apologize for that. I will provide a code comparison in my next e-mail, after I go through the existing RAM drive code.