From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id ABCDB239; Mon, 27 Nov 2017 10:00:44 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 15BB981DE4; Mon, 27 Nov 2017 09:00:44 +0000 (UTC) Received: from [10.36.112.50] (ovpn-112-50.ams2.redhat.com [10.36.112.50]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 85DD85EDE8; Mon, 27 Nov 2017 09:00:41 +0000 (UTC) To: Victor Kaplansky Cc: dev@dpdk.org, yliu@fridaylinux.org, tiwei bie , jianfeng tan , stable@dpdk.org, jfreiman@redhat.com References: <20171124180826.18439-1-maxime.coquelin@redhat.com> <20171124180826.18439-3-maxime.coquelin@redhat.com> <1760091245.45753170.1511770580954.JavaMail.zimbra@redhat.com> <0a577e7b-2d90-04ba-3fac-f70192970a09@redhat.com> <1602820578.45759784.1511772154833.JavaMail.zimbra@redhat.com> From: Maxime Coquelin Message-ID: <26f6b686-fffe-2d2b-7808-62d3cddb4cbf@redhat.com> Date: Mon, 27 Nov 2017 10:00:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1602820578.45759784.1511772154833.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 27 Nov 2017 09:00:44 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v2 2/3] vhost: protect dirty logging against logging base change X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 09:00:46 -0000 On 11/27/2017 09:42 AM, Victor Kaplansky wrote: > > > ----- Original Message ----- >> From: "Maxime Coquelin" >> To: "Victor Kaplansky" >> Cc: dev@dpdk.org, yliu@fridaylinux.org, "tiwei bie" , "jianfeng tan" , >> stable@dpdk.org, jfreiman@redhat.com >> Sent: Monday, November 27, 2017 10:27:22 AM >> Subject: Re: [PATCH v2 2/3] vhost: protect dirty logging against logging base change >> >> Hi Victor, >> >> On 11/27/2017 09:16 AM, Victor Kaplansky wrote: >>> Hi, >>> >>> While I agree that taking full fledged lock by rte_rwlock_read_lock() >>> solves the race condition, >>> I'm afraid that it would be too expensive in case when logging is off, >>> since it introduces >>> acquiring and releasing lock into the main flow of ring updates. >> >> Actually my v2 fixes the performance penalty when logging is off. The >> lock is now taken after the logging feature check. >> >> But still, I agree logging on case will suffer from a performance >> penalty. > > Yes, checking of logging feature is better than nothing, but VHOST_F_LOG_ALL > marks only whether logging is supported by the device and not if > logging is in the action. Thus, any guest will hit the performance > degradation even not during migration. My understanding is that VHOST_USER_SET_FEATURES is called again with VHOST_F_LOG_ALL on on migration start and with VHOST_F_LOG_ALL off on migration stop. > > >> >>> It is OK for now, as it fixes the bug, but we need to perform more careful >>> performance measurements, >>> and see whether the performance degradation is not too prohibitive. >>> >>> As alternative, we may consider using more light weighted busy looping. >> >> I think it will end up almost being the same, as both threads will need >> to busy loop. PMD thread to be sure the protocol thread isn't being >> unmapping the region before doing the logging, and protocol thread to be >> sure the PMD thread is not doing logging before handling the set log >> base. >> > > I'm not fully aware how rte_rwlock_read_lock() is implemented, but > theoretically busy looping should be much cheaper in cases when > taking lock by one side is very rare. we could improve it by only taking the lock once per burst instead of per page logging, as we don't care the protocol thread waits a bit more when it wants to remap the area. >> Maybe you have something else in mind? >> >>> Also, lets fix by this series the __sync_fetch_and_or_8 -> >>> __sync_fetch_and_or, >>> as it may improve the performance slightly. >> >> Sure, this can be done, but it would need to be benchmarked first. > > Agree. >> >> Regards, >> Maxime >>