Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D46A29D8B for ; Fri, 19 Dec 2014 14:38:44 +0000 (UTC) Received: (qmail 23920 invoked by uid 500); 19 Dec 2014 14:38:44 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 23868 invoked by uid 500); 19 Dec 2014 14:38:44 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 23857 invoked by uid 99); 19 Dec 2014 14:38:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Dec 2014 14:38:43 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ivan@visualsvn.com designates 209.85.216.44 as permitted sender) Received: from [209.85.216.44] (HELO mail-qa0-f44.google.com) (209.85.216.44) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Dec 2014 14:38:39 +0000 Received: by mail-qa0-f44.google.com with SMTP id bm13so680438qab.17 for ; Fri, 19 Dec 2014 06:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=visualsvn.com; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=GbP7j23OqAZyDrCnlRV6z2glQfCOicJyTzAH4HUWZII=; b=fgQ4RSQySy1qV/Rk1YMPjKV3ORyGLq3Bkuzao6d0bVQI6NI7um4nNAnwfVAlW2wxH0 Sf3S8rETw4RucoZXQnIvdzBIGJzhlP336bOWnUtyCq5gu53qZwHkgPJ/fUjiN8smf8ju shqzz35Ix5Aac/L+tLvBbMNoyLJB3otcEXzqs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GbP7j23OqAZyDrCnlRV6z2glQfCOicJyTzAH4HUWZII=; b=iY4s6/JdE9jqbKEUKb8vFLQkWOa2U6MnD0OCOTOcrDgSGg6JMjGjuaGgaSEsxtJcr8 br+eakdXL4r812avTVglRCunqcPrf7ON0olfXtL7xVkAaWMLTBO4mZdeXGaP9T73biVw ojtwf7F8Xovt6TpeUfYxIeawmHso9RD13ciFXw4PJkMqQn9bf+/oaeeJwTC8VytGrRpq CBJfq+lBbRQeiSx3GcR7rcQzTg1rogPRmludkVOtqMXGhS5MEgOI4octPuYtTcOEzbag tS1+9/eZl5iNipR3zirKpPvRc5R0Ou4fJhs4woETT+jEdbfVzXoY/KFQQNQ1QvTqTdD2 ptvA== X-Gm-Message-State: ALoCoQlYTbcKp2n/ry5Rd8DOZBcTYlR1LRaJU/3dPtmdMAUILZdTR0JWYD/GfKYvbLjan+CqKSXC X-Received: by 10.224.165.148 with SMTP id i20mr13703339qay.67.1418999853752; Fri, 19 Dec 2014 06:37:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.140.146 with HTTP; Fri, 19 Dec 2014 06:37:13 -0800 (PST) From: Ivan Zhakov Date: Fri, 19 Dec 2014 17:37:13 +0300 Message-ID: Subject: FSFS caching and apr_thread_rwlock_t performance on Windows To: Subversion Development Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org Originally FSFS caching implementation was using apr_thread_mutex_t to serialize access to shared data. In r1346122 [1] implementation was switched to apr_thread_rw_lock_t to improve performance. This change was released in Subversion 1.8.0 Unfortunately current apr_thread_rwlock_t implementation is very slow on Windows. As quick workaround FSFS code was patched to select apr_thread_mutex_t or apr_thread_rwlock_t() depending of platform on compile time (r1611380 [2]). In further investigation Bert found why apr_thread_rwlock_t() so slow on Windows: implementation uses kernel level mutex object instead of lightweight critical section (critical sections are also used in apr_thread_mutex_t in most cases). The simple patch to switch apr_thread_rwlock_t() implementation to use critical sections (through apr_thread_mutex_t) was proposed on APR development mailing list [3], but patch was not commited nor reviewed. So the current situation is: 1. APR has performance problem on Windows that hurts Subversion 1.8.x and trunk 2. Subversion trunk has workaround for this specific problem at compile time 3. Patch proposed to APR mailing list, without any reaction for three months >From my point of view the proposed patch is straightforward and Bert stated that it makes apr_thread_rwlock_t 10 to 140 times more efficient on Windows. So the best option will be to commit Bert's patch, but I cannot do this since I'm not APR committer :( Thoughts? [1] http://svn.apache.org/r1346122 [2] http://svn.apache.org/r1611380 [3] http://mail-archives.apache.org/mod_mbox/apr-dev/201408.mbox/%3C31e101cfae30%248670db00%2493529100%24%40qqmail.nl%3E -- Ivan Zhakov