Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765037AbcJaKGg (ORCPT ); Mon, 31 Oct 2016 06:06:36 -0400 Received: from mga07.intel.com ([134.134.136.100]:3939 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1764924AbcJaKGd (ORCPT ); Mon, 31 Oct 2016 06:06:33 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,426,1473145200"; d="scan'208";a="25621517" From: "Van De Ven, Arjan" To: Vitaly Kuznetsov , KY Srinivasan CC: "devel@linuxdriverproject.org" , "linux-kernel@vger.kernel.org" , Haiyang Zhang Subject: RE: [PATCH] Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg() Thread-Topic: [PATCH] Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg() Thread-Index: AQHSM15OwYJ91dcgj0KEgvg+ku0EVaDCVfsw Date: Mon, 31 Oct 2016 10:06:30 +0000 Message-ID: <0575AF4FD06DD142AD198903C74E1CC85882071F@ORSMSX103.amr.corp.intel.com> References: <1477480307-5546-1-git-send-email-vkuznets@redhat.com> <87shrcbzqz.fsf@vitty.brq.redhat.com> In-Reply-To: <87shrcbzqz.fsf@vitty.brq.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzJhNjcxNGMtZjU4OS00NjdmLWE2Y2MtMWY1ZWM2ZDcwNmRkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImlzZEZGeEMwcXN1UjB1YllVMzZ3dHZxandkdjF4d2RGV0tJNmhPM0hFTzg9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u9VA6d1m028012 Content-Length: 467 Lines: 11 > Ok, > > I actually tested boot time with my patch and didn't see a difference > (so I guess our first attempt to send messages usually succeeds) but if > we're concearned about less-than-a-second boot time we'd rather keep the > microseonds delay for first several attempts. I'll do v2. of course we care about less-than-a-second boot time.. it's a virtual machine.. there's no reason the kernel should ever take more than 100 msec total (including all drivers)