Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756419Ab3EXSrv (ORCPT ); Fri, 24 May 2013 14:47:51 -0400 Received: from merlin.infradead.org ([205.233.59.134]:39581 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751579Ab3EXSru (ORCPT ); Fri, 24 May 2013 14:47:50 -0400 Date: Fri, 24 May 2013 20:47:27 +0200 From: Jens Axboe To: OS Engineering Cc: LKML , Padmini Balasubramaniyan , Amit Phansalkar Subject: Re: EnhanceIO(TM) caching driver features [1/3] Message-ID: <20130524184727.GQ29680@kernel.dk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1860 Lines: 44 On Fri, May 24 2013, OS Engineering wrote: > Hi Jens and Kernel Gurus, [snip] Thanks for writing all of this up, but I'm afraid it misses the point somewhat. As stated previously, we have (now) two existing competing implementations in the kernel. I'm looking for justification on why YOUR solution is better. A writeup and documentation on error handling details is nice and all, but it doesn't answer the key important questions. Lets say somebody sends in a patch that he/she claims improves memory management performance. To justify such a patch (or any patch, really), the maintenance burden vs performance benefit needs to be quantified. Such a person had better supply a set of before and after numbers, such that the benefit can be quantified. It's really the same with your solution. You mention "the solution has been proven in independent testing, such as testing by Demartek.". I have no idea what this testing is, what they ran, compared with, etc. So, to put it bluntly, I need to see some numbers. Run relevant workloads on EnhanceIO, bcache, dm-cache. Show why EnhanceIO is better. Then we can decide whether it really is the superior solution. Or, perhaps, it turns out there are inefficiencies in eg bcache/dm-cache that could be fixed up. Usually I'm not such a stickler for including new code. But a new driver is different than EnhanceIO. If somebody submitted a patch to add a newly written driver for hw that we already have a driver for, that would be similar situation. The executive summary: your writeup was good, but we need some relevant numbers to look at too. -- Jens Axboe -- 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/