From mboxrd@z Thu Jan 1 00:00:00 1970 From: Or Gerlitz Subject: Re: [PATCH v1 for-next 00/16] On demand paging Date: Wed, 17 Sep 2014 18:18:46 +0300 Message-ID: <5419A656.2050004@mellanox.com> References: <1404377069-20585-1-git-send-email-haggaie@mellanox.com> <5405D2D8.1040700@mellanox.com> <540F0CD8.9070002@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Roland Dreier Cc: Or Gerlitz , Latchesar Ionkov , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Greg Kroah-Hartman , Sagi Grimberg , Linux Kernel , Haggai Eran List-Id: linux-rdma@vger.kernel.org On 9/13/2014 12:16 AM, Or Gerlitz wrote: > Per your request we provided the information on tests conducted with > the patches. > > Note that the patches can't really disrupt existing applications that > don't set the new IB_ACCESS_ON_DEMAND MR flag when they register > memory. Also the whole set of changes to the umem area is dependent on building with > CONFIG_INFINIBAND_ON_DEMAND_PAGING -- all in all, everything is in > place for protecting against potential regression that this series > could introduce. > > As you didn't provide any feedback for > six months, and we have all > the above in place (report on stability tests, performance data and > mechanics to avoid regressions) I think it would be fair to get this > picked for the coming merge window, thoughts? Roland, Can you please comment here, not only that you didn't provide any feedback on the patches, you are even not willing to respond if the the data we gave addresses your questions on testing and performance. Are you planning to pick this to the next merge window? Or. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755463AbaIQPS7 (ORCPT ); Wed, 17 Sep 2014 11:18:59 -0400 Received: from eu1sys200aog125.obsmtp.com ([207.126.144.159]:48304 "EHLO eu1sys200aog125.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754363AbaIQPS5 (ORCPT ); Wed, 17 Sep 2014 11:18:57 -0400 Message-ID: <5419A656.2050004@mellanox.com> Date: Wed, 17 Sep 2014 18:18:46 +0300 From: Or Gerlitz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Roland Dreier CC: Or Gerlitz , Latchesar Ionkov , "linux-rdma@vger.kernel.org" , Greg Kroah-Hartman , Sagi Grimberg , "Linux Kernel" , Haggai Eran Subject: Re: [PATCH v1 for-next 00/16] On demand paging References: <1404377069-20585-1-git-send-email-haggaie@mellanox.com> <5405D2D8.1040700@mellanox.com> <540F0CD8.9070002@mellanox.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.5.164] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/13/2014 12:16 AM, Or Gerlitz wrote: > Per your request we provided the information on tests conducted with > the patches. > > Note that the patches can't really disrupt existing applications that > don't set the new IB_ACCESS_ON_DEMAND MR flag when they register > memory. Also the whole set of changes to the umem area is dependent on building with > CONFIG_INFINIBAND_ON_DEMAND_PAGING -- all in all, everything is in > place for protecting against potential regression that this series > could introduce. > > As you didn't provide any feedback for > six months, and we have all > the above in place (report on stability tests, performance data and > mechanics to avoid regressions) I think it would be fair to get this > picked for the coming merge window, thoughts? Roland, Can you please comment here, not only that you didn't provide any feedback on the patches, you are even not willing to respond if the the data we gave addresses your questions on testing and performance. Are you planning to pick this to the next merge window? Or.