Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753097AbYLSR5b (ORCPT ); Fri, 19 Dec 2008 12:57:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751763AbYLSR5S (ORCPT ); Fri, 19 Dec 2008 12:57:18 -0500 Received: from mout-bounce.kundenserver.de ([212.227.17.1]:57665 "EHLO mout-bounce.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751660AbYLSR5R (ORCPT ); Fri, 19 Dec 2008 12:57:17 -0500 Message-ID: <494BE08D.30101@vlnb.net> Date: Fri, 19 Dec 2008 20:57:33 +0300 From: Vladislav Bolkhovitin User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Andi Kleen CC: linux-mm@kvack.org, Christoph Hellwig , James Bottomley , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, scst-devel@lists.sourceforge.net, Bart Van Assche , netdev@vger.kernel.org Subject: Re: [RFC]: Support for zero-copy TCP transmit of user space data References: <4941590F.3070705@vlnb.net> <1229022734.3266.67.camel@localhost.localdomain> <4942BAB8.4050007@vlnb.net> <1229110673.3262.94.camel@localhost.localdomain> <49469ADB.6010709@vlnb.net> <20081215231801.GA27168@infradead.org> <4947FA1C.2090509@vlnb.net> <494A97DD.7080503@vlnb.net> <87zlisz9pg.fsf@basil.nowhere.org> <494BDBFC.7060707@vlnb.net> <20081219180009.GP25779@one.firstfloor.org> In-Reply-To: <20081219180009.GP25779@one.firstfloor.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/vUsux8DobkJubLjp60JWQBTsuBLrfwmDULez u4v9QkD/TpJU9sRFrUfMGWngx4DNQl8B5arLnZTwHtmdfj0/uk +/hIOK8Hia/i13K+TlLQg== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1284 Lines: 31 Andi Kleen, on 12/19/2008 09:00 PM wrote: >> Sure, this is why I propose to disable that option by default in >> distribution kernels, so it would produce no harm. > > That would make the option useless for most users. You might as well > not bother merging then. I believe 99.(9)% of users prefer don't patch kernel, if possible. >> first, only then enable that option, then rebuild the kernel. (I'm >> repeating it to make sure you didn't miss this my point; it was in the >> part of my original message, which you cut out.) > > That was such a ridiculous suggestion, I didn't take it seriously. > > Also it should be really not rocket science to use a separate > table for this. Sorry, what do you mean? If usage of something like a hash table to map pages to the corresponding iSCSI commands, this approach was evaluated and rejected, because it wouldn't provide much performance increase, which would worth the effort. See details in the end of the patch description in http://lkml.org/lkml/2008/12/10/296 Thanks, Vlad -- 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/