From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F478ECAAD1 for ; Thu, 1 Sep 2022 17:36:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234057AbiIARgO (ORCPT ); Thu, 1 Sep 2022 13:36:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234551AbiIARfg (ORCPT ); Thu, 1 Sep 2022 13:35:36 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF59645041 for ; Thu, 1 Sep 2022 10:35:21 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id v5-20020a2583c5000000b006964324be8cso4905030ybm.14 for ; Thu, 01 Sep 2022 10:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date; bh=kDz45+x8leBVOf7Bdp0WiDEao4W3YXxkJImYKeLiow8=; b=UJ2NJSigmjvs38+mtpjC0YPaCWUde6cB0UL/bLufaGhMosguVjiiFe1oszFm36/Odc sUfw69wiCGaI3T90u9gbLBluz/hph0cewPRzHoAQw666Ao4RCcUg+CRGBoTlLAh+P8fw d6pa6e1ROBBUZrnr2K/YAABtJnqT1xqAFjYdpdHHFOI0Qj4R7XA51PC6fSlMGidZfaTe auU6PBRWiLtEO8ZKkl2afbBFNVW7/F0No/gyQzvcoDCPswV1JpNDwaFi4dzPo2uGVvT+ KyAW7FzT4zbe/qv1aeGuBipeT7ieMPk/X1LylsgIncU0zCOpr2t23+stO/KnyWKxRNvu oj8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date; bh=kDz45+x8leBVOf7Bdp0WiDEao4W3YXxkJImYKeLiow8=; b=AaOHRQQWquBPLHqFWfEiT8CyhtRX9Wuj0sGcnuiQylR9y/UH0zTd1a8ePGQMSXqAVd aXUNVbpo7kYioSyV85KswfTzH5xBAlcbfG/weRAEO1cHEU9pRQIr0A1NfZUvxtlkxTuo 0OkHoiFJ7S7ksQCIDdo8qRnq5rQPF9b2eYLiH1h4hS0+p5yOd2q8k0lqgjAEoRa05PLc LiP53UXDGHZPhS1rPYlOlqdGgeiHepxpM4EEEW9+m9NcimZeOZYZU21VU1po88/3bo0O ajILZH2QuugWIhwy2yfEoL3DaEzbSCRhNh6e+Of4n56O1BUexNkcAkZ/LcXremTqSsBo YggA== X-Gm-Message-State: ACgBeo2GTSal4VFRCFb9Yd2wjLQk/RSBaya9sr4jP2drbeBlBejyj8uH oPNw519Fx6XFf973TyValJMi0WX/T0I= X-Google-Smtp-Source: AA6agR7afRN1POoQY9p1igScMyaFRYqs4/PVRqG8JF8uqVSGzSSN48hhlfxus/tnBm8aq/2o/zV00jvOX/w= X-Received: from surenb-desktop.mtv.corp.google.com ([2620:15c:211:200:1bfc:e7ee:6530:4449]) (user=surenb job=sendgmr) by 2002:a81:9e53:0:b0:340:8556:472d with SMTP id n19-20020a819e53000000b003408556472dmr23620124ywj.197.1662053720792; Thu, 01 Sep 2022 10:35:20 -0700 (PDT) Date: Thu, 1 Sep 2022 10:34:48 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.37.2.789.g6183377224-goog Message-ID: <20220901173516.702122-1-surenb@google.com> Subject: [RFC PATCH RESEND 00/28] per-VMA locks proposal From: Suren Baghdasaryan To: akpm@linux-foundation.org Cc: michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, surenb@google.com, kernel-team@android.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Resending to fix the issue with the In-Reply-To tag in the original submission at [4]. This is a proof of concept for per-vma locks idea that was discussed during SPF [1] discussion at LSF/MM this year [2], which concluded with suggestion that =E2=80=9Ca reader/writer semaphore could be put into the VM= A itself; that would have the effect of using the VMA as a sort of range lock. There would still be contention at the VMA level, but it would be an improvement.=E2=80=9D This patchset implements this suggested approach. When handling page faults we lookup the VMA that contains the faulting page under RCU protection and try to acquire its lock. If that fails we fall back to using mmap_lock, similar to how SPF handled this situation. One notable way the implementation deviates from the proposal is the way VMAs are marked as locked. Because during some of mm updates multiple VMAs need to be locked until the end of the update (e.g. vma_merge, split_vma, etc). Tracking all the locked VMAs, avoiding recursive locks and other complications would make the code more complex. Therefore we provide a way to "mark" VMAs as locked and then unmark all locked VMAs all at once. This is done using two sequence numbers - one in the vm_area_struct and one in the mm_struct. VMA is considered locked when these sequence numbers are equal. To mark a VMA as locked we set the sequence number in vm_area_struct to be equal to the sequence number in mm_struct. To unlock all VMAs we increment mm_struct's seq number. This allows for an efficient way to track locked VMAs and to drop the locks on all VMAs at the end of the update. The patchset implements per-VMA locking only for anonymous pages which are not in swap. If the initial proposal is considered acceptable, then support for swapped and file-backed page faults will be added. Performance benchmarks show similar although slightly smaller benefits as with SPF patchset (~75% of SPF benefits). Still, with lower complexity this approach might be more desirable. The patchset applies cleanly over 6.0-rc3 The tree for testing is posted at [3] [1] https://lore.kernel.org/all/20220128131006.67712-1-michel@lespinasse.or= g/ [2] https://lwn.net/Articles/893906/ [3] https://github.com/surenbaghdasaryan/linux/tree/per_vma_lock_rfc [4] https://lore.kernel.org/all/20220829212531.3184856-1-surenb@google.com/ Laurent Dufour (2): powerc/mm: try VMA lock-based page fault handling first powerpc/mm: define ARCH_SUPPORTS_PER_VMA_LOCK Michel Lespinasse (1): mm: rcu safe VMA freeing Suren Baghdasaryan (25): mm: introduce CONFIG_PER_VMA_LOCK mm: introduce __find_vma to be used without mmap_lock protection mm: move mmap_lock assert function definitions mm: add per-VMA lock and helper functions to control it mm: mark VMA as locked whenever vma->vm_flags are modified kernel/fork: mark VMAs as locked before copying pages during fork mm/khugepaged: mark VMA as locked while collapsing a hugepage mm/mempolicy: mark VMA as locked when changing protection policy mm/mmap: mark VMAs as locked in vma_adjust mm/mmap: mark VMAs as locked before merging or splitting them mm/mremap: mark VMA as locked while remapping it to a new address range mm: conditionally mark VMA as locked in free_pgtables and unmap_page_range mm: mark VMAs as locked before isolating them mm/mmap: mark adjacent VMAs as locked if they can grow into unmapped area kernel/fork: assert no VMA readers during its destruction mm/mmap: prevent pagefault handler from racing with mmu_notifier registration mm: add FAULT_FLAG_VMA_LOCK flag mm: disallow do_swap_page to handle page faults under VMA lock mm: introduce per-VMA lock statistics mm: introduce find_and_lock_anon_vma to be used from arch-specific code x86/mm: try VMA lock-based page fault handling first x86/mm: define ARCH_SUPPORTS_PER_VMA_LOCK arm64/mm: try VMA lock-based page fault handling first arm64/mm: define ARCH_SUPPORTS_PER_VMA_LOCK kernel/fork: throttle call_rcu() calls in vm_area_free arch/arm64/Kconfig | 1 + arch/arm64/mm/fault.c | 36 +++++++++ arch/powerpc/mm/fault.c | 41 ++++++++++ arch/powerpc/platforms/powernv/Kconfig | 1 + arch/powerpc/platforms/pseries/Kconfig | 1 + arch/x86/Kconfig | 1 + arch/x86/mm/fault.c | 36 +++++++++ drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- fs/proc/task_mmu.c | 1 + fs/userfaultfd.c | 6 ++ include/linux/mm.h | 104 ++++++++++++++++++++++++- include/linux/mm_types.h | 33 ++++++-- include/linux/mmap_lock.h | 37 ++++++--- include/linux/vm_event_item.h | 6 ++ include/linux/vmstat.h | 6 ++ kernel/fork.c | 75 +++++++++++++++++- mm/Kconfig | 13 ++++ mm/Kconfig.debug | 8 ++ mm/init-mm.c | 6 ++ mm/internal.h | 4 +- mm/khugepaged.c | 1 + mm/madvise.c | 1 + mm/memory.c | 82 ++++++++++++++++--- mm/mempolicy.c | 6 +- mm/mlock.c | 2 + mm/mmap.c | 60 ++++++++++---- mm/mprotect.c | 1 + mm/mremap.c | 1 + mm/nommu.c | 2 + mm/oom_kill.c | 3 +- mm/vmstat.c | 6 ++ 31 files changed, 531 insertions(+), 54 deletions(-) --=20 2.37.2.789.g6183377224-goog From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B466AECAAD1 for ; Thu, 1 Sep 2022 17:36:00 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4MJSrH1jQqz3brd for ; Fri, 2 Sep 2022 03:35:59 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=UJ2NJSig; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--surenb.bounces.google.com (client-ip=2607:f8b0:4864:20::114a; helo=mail-yw1-x114a.google.com; envelope-from=3wo0qywykdjuhjg3c05dd5a3.1dba7cjmee1-23ka7hih.doaz0h.dg5@flex--surenb.bounces.google.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=UJ2NJSig; dkim-atps=neutral Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4MJSqd3fv2z2xZV for ; Fri, 2 Sep 2022 03:35:24 +1000 (AEST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-335ff2ef600so235527497b3.18 for ; Thu, 01 Sep 2022 10:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date; bh=kDz45+x8leBVOf7Bdp0WiDEao4W3YXxkJImYKeLiow8=; b=UJ2NJSigmjvs38+mtpjC0YPaCWUde6cB0UL/bLufaGhMosguVjiiFe1oszFm36/Odc sUfw69wiCGaI3T90u9gbLBluz/hph0cewPRzHoAQw666Ao4RCcUg+CRGBoTlLAh+P8fw d6pa6e1ROBBUZrnr2K/YAABtJnqT1xqAFjYdpdHHFOI0Qj4R7XA51PC6fSlMGidZfaTe auU6PBRWiLtEO8ZKkl2afbBFNVW7/F0No/gyQzvcoDCPswV1JpNDwaFi4dzPo2uGVvT+ KyAW7FzT4zbe/qv1aeGuBipeT7ieMPk/X1LylsgIncU0zCOpr2t23+stO/KnyWKxRNvu oj8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date; bh=kDz45+x8leBVOf7Bdp0WiDEao4W3YXxkJImYKeLiow8=; b=yB3+TlxxUwgZ97ieSRM8ftR7U1YbYSg9gZ91WR06a22Vogj9KjUqDnMyM3ryaHtxZC Urtyi+QLaEgVNr82XoLJ3aks3SijkEZTrv/XFdabrt2yMvJ62UKenlq934AwpxlkxCd/ u6GkHehvwM8DQowbuRL8/5GrKJHz+l01wzodk4zDM0qEZAvnqNIMhAXNpGhe4aF039DJ AJ9UC/WwsFXqaNbA4v8HacEk56tKi2qACai0LNrOGB+9aRXMAHxToaUTSSMHOv9v/HBC Qkr/gwwK+BqEEHz8gF4Q9zDksZ5r3sNkBulr61m43Rn3N8anKUz2WN5i+kys98btsI3h 0mTQ== X-Gm-Message-State: ACgBeo2CwnA/mD+q9yQpAr2g+aYQh7Kvma/Sgh1b4IP/VtwGgrU6GrUz j75gK4G2UI3IZ59dGxsT4vLFNmq0a8k= X-Google-Smtp-Source: AA6agR7afRN1POoQY9p1igScMyaFRYqs4/PVRqG8JF8uqVSGzSSN48hhlfxus/tnBm8aq/2o/zV00jvOX/w= X-Received: from surenb-desktop.mtv.corp.google.com ([2620:15c:211:200:1bfc:e7ee:6530:4449]) (user=surenb job=sendgmr) by 2002:a81:9e53:0:b0:340:8556:472d with SMTP id n19-20020a819e53000000b003408556472dmr23620124ywj.197.1662053720792; Thu, 01 Sep 2022 10:35:20 -0700 (PDT) Date: Thu, 1 Sep 2022 10:34:48 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.37.2.789.g6183377224-goog Message-ID: <20220901173516.702122-1-surenb@google.com> Subject: [RFC PATCH RESEND 00/28] per-VMA locks proposal From: Suren Baghdasaryan To: akpm@linux-foundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: michel@lespinasse.org, joelaf@google.com, songliubraving@fb.com, mhocko@suse.com, david@redhat.com, peterz@infradead.org, bigeasy@linutronix.de, peterx@redhat.com, dhowells@redhat.com, linux-mm@kvack.org, jglisse@google.com, dave@stgolabs.net, minchan@google.com, x86@kernel.org, hughd@google.com, willy@infradead.org, laurent.dufour@fr.ibm.com, mgorman@suse.de, rientjes@google.com, axelrasmussen@google.com, kernel-team@android.com, paulmck@kernel.org, liam.howlett@oracle.com, luto@kernel.org, ldufour@linux.ibm.com, surenb@google.com, vbabka@suse.cz, linux-arm-kernel@lists.infradead.org, kent.overstreet@linux.dev, linux-kernel@vger.kernel.org, hannes@cmpxchg.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Resending to fix the issue with the In-Reply-To tag in the original submission at [4]. This is a proof of concept for per-vma locks idea that was discussed during SPF [1] discussion at LSF/MM this year [2], which concluded with suggestion that =E2=80=9Ca reader/writer semaphore could be put into the VM= A itself; that would have the effect of using the VMA as a sort of range lock. There would still be contention at the VMA level, but it would be an improvement.=E2=80=9D This patchset implements this suggested approach. When handling page faults we lookup the VMA that contains the faulting page under RCU protection and try to acquire its lock. If that fails we fall back to using mmap_lock, similar to how SPF handled this situation. One notable way the implementation deviates from the proposal is the way VMAs are marked as locked. Because during some of mm updates multiple VMAs need to be locked until the end of the update (e.g. vma_merge, split_vma, etc). Tracking all the locked VMAs, avoiding recursive locks and other complications would make the code more complex. Therefore we provide a way to "mark" VMAs as locked and then unmark all locked VMAs all at once. This is done using two sequence numbers - one in the vm_area_struct and one in the mm_struct. VMA is considered locked when these sequence numbers are equal. To mark a VMA as locked we set the sequence number in vm_area_struct to be equal to the sequence number in mm_struct. To unlock all VMAs we increment mm_struct's seq number. This allows for an efficient way to track locked VMAs and to drop the locks on all VMAs at the end of the update. The patchset implements per-VMA locking only for anonymous pages which are not in swap. If the initial proposal is considered acceptable, then support for swapped and file-backed page faults will be added. Performance benchmarks show similar although slightly smaller benefits as with SPF patchset (~75% of SPF benefits). Still, with lower complexity this approach might be more desirable. The patchset applies cleanly over 6.0-rc3 The tree for testing is posted at [3] [1] https://lore.kernel.org/all/20220128131006.67712-1-michel@lespinasse.or= g/ [2] https://lwn.net/Articles/893906/ [3] https://github.com/surenbaghdasaryan/linux/tree/per_vma_lock_rfc [4] https://lore.kernel.org/all/20220829212531.3184856-1-surenb@google.com/ Laurent Dufour (2): powerc/mm: try VMA lock-based page fault handling first powerpc/mm: define ARCH_SUPPORTS_PER_VMA_LOCK Michel Lespinasse (1): mm: rcu safe VMA freeing Suren Baghdasaryan (25): mm: introduce CONFIG_PER_VMA_LOCK mm: introduce __find_vma to be used without mmap_lock protection mm: move mmap_lock assert function definitions mm: add per-VMA lock and helper functions to control it mm: mark VMA as locked whenever vma->vm_flags are modified kernel/fork: mark VMAs as locked before copying pages during fork mm/khugepaged: mark VMA as locked while collapsing a hugepage mm/mempolicy: mark VMA as locked when changing protection policy mm/mmap: mark VMAs as locked in vma_adjust mm/mmap: mark VMAs as locked before merging or splitting them mm/mremap: mark VMA as locked while remapping it to a new address range mm: conditionally mark VMA as locked in free_pgtables and unmap_page_range mm: mark VMAs as locked before isolating them mm/mmap: mark adjacent VMAs as locked if they can grow into unmapped area kernel/fork: assert no VMA readers during its destruction mm/mmap: prevent pagefault handler from racing with mmu_notifier registration mm: add FAULT_FLAG_VMA_LOCK flag mm: disallow do_swap_page to handle page faults under VMA lock mm: introduce per-VMA lock statistics mm: introduce find_and_lock_anon_vma to be used from arch-specific code x86/mm: try VMA lock-based page fault handling first x86/mm: define ARCH_SUPPORTS_PER_VMA_LOCK arm64/mm: try VMA lock-based page fault handling first arm64/mm: define ARCH_SUPPORTS_PER_VMA_LOCK kernel/fork: throttle call_rcu() calls in vm_area_free arch/arm64/Kconfig | 1 + arch/arm64/mm/fault.c | 36 +++++++++ arch/powerpc/mm/fault.c | 41 ++++++++++ arch/powerpc/platforms/powernv/Kconfig | 1 + arch/powerpc/platforms/pseries/Kconfig | 1 + arch/x86/Kconfig | 1 + arch/x86/mm/fault.c | 36 +++++++++ drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- fs/proc/task_mmu.c | 1 + fs/userfaultfd.c | 6 ++ include/linux/mm.h | 104 ++++++++++++++++++++++++- include/linux/mm_types.h | 33 ++++++-- include/linux/mmap_lock.h | 37 ++++++--- include/linux/vm_event_item.h | 6 ++ include/linux/vmstat.h | 6 ++ kernel/fork.c | 75 +++++++++++++++++- mm/Kconfig | 13 ++++ mm/Kconfig.debug | 8 ++ mm/init-mm.c | 6 ++ mm/internal.h | 4 +- mm/khugepaged.c | 1 + mm/madvise.c | 1 + mm/memory.c | 82 ++++++++++++++++--- mm/mempolicy.c | 6 +- mm/mlock.c | 2 + mm/mmap.c | 60 ++++++++++---- mm/mprotect.c | 1 + mm/mremap.c | 1 + mm/nommu.c | 2 + mm/oom_kill.c | 3 +- mm/vmstat.c | 6 ++ 31 files changed, 531 insertions(+), 54 deletions(-) --=20 2.37.2.789.g6183377224-goog From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 22101ECAAD3 for ; Thu, 1 Sep 2022 17:36:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: Mime-Version:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=RE2QaOF6uVY8v50OEDDKDS/Sd+c/WS8il5URuw+Xsoo=; b=2Ku YPo+j6vWBXU8kmXXN7uG/x+JNqg4i7s0FjbwyDhs/HSAFENoYeIexyUxq+v96exqyvOWlPyj+ijr/ F/HtlZfsoemOhlVrbAsu0kEn6LfQzIrKPEXc3WmiHvqZg8BXTQo/voOHI8pYIsBHcpZeRKM4vPZ18 PB4X7TwEql6xMsspHiRgOdwZZohMaQkQkA6GnE96b+fdl72qDX+0oXASrZAe+//DI83VH5s4AMmC7 9L+I9Q6z5KupXhHC7lFAQRt0le5ReXUfQKBUIJuJyFrIWkkKrBVrkfY6UqGnMSSU49i0ZD+OLHC0p qGRe1hPZc+cjDc1HpyZItuMKwOTXQDw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTo6C-00DbJO-Em; Thu, 01 Sep 2022 17:35:28 +0000 Received: from mail-yb1-xb4a.google.com ([2607:f8b0:4864:20::b4a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTo68-00DbFw-LF for linux-arm-kernel@lists.infradead.org; Thu, 01 Sep 2022 17:35:26 +0000 Received: by mail-yb1-xb4a.google.com with SMTP id f3-20020a056902038300b00696588a0e87so3562551ybs.3 for ; Thu, 01 Sep 2022 10:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:from:to:cc:subject:date; bh=kDz45+x8leBVOf7Bdp0WiDEao4W3YXxkJImYKeLiow8=; b=UJ2NJSigmjvs38+mtpjC0YPaCWUde6cB0UL/bLufaGhMosguVjiiFe1oszFm36/Odc sUfw69wiCGaI3T90u9gbLBluz/hph0cewPRzHoAQw666Ao4RCcUg+CRGBoTlLAh+P8fw d6pa6e1ROBBUZrnr2K/YAABtJnqT1xqAFjYdpdHHFOI0Qj4R7XA51PC6fSlMGidZfaTe auU6PBRWiLtEO8ZKkl2afbBFNVW7/F0No/gyQzvcoDCPswV1JpNDwaFi4dzPo2uGVvT+ KyAW7FzT4zbe/qv1aeGuBipeT7ieMPk/X1LylsgIncU0zCOpr2t23+stO/KnyWKxRNvu oj8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:from:subject:message-id :mime-version:date:x-gm-message-state:from:to:cc:subject:date; bh=kDz45+x8leBVOf7Bdp0WiDEao4W3YXxkJImYKeLiow8=; b=WKef2rEcrcQc+yeqTffV7aYnxjXPS+8ggw2rWLiYYnCKpVaRGRtzGRWYpcHkiJOCOd Aps5cBE4gxQrhsBurkutNjnnnO6APPXqcERXLl8PNo0immZK266nrIFoDOvoQO2920Vo PA+LnJrhZazV4YvaKAKvAMh4X+1wLd/wTldZEKh5DQY1jjHJjGR/r11GezuUSkwnfM21 Pkn9JddDXiZAlTeglAXyMT+EQBU8Bh4vxrSPN/vWTuaElNIQqh2YHhx5LwmPZcdUAA/W EZvJcx01NTok7pBotWwFX+k4nlxudJVnvlGGTnTitC6LjdkiaN5b1O9WnsF3D9e4fUqq +vkQ== X-Gm-Message-State: ACgBeo07gG+yDKNgzRUKq9GudbxL+uyvLymlF5vsZt81TE8mav2l8Ab2 UO/hQbRi/bGb2WnMK7q0GbhWuYM5k7k= X-Google-Smtp-Source: AA6agR7afRN1POoQY9p1igScMyaFRYqs4/PVRqG8JF8uqVSGzSSN48hhlfxus/tnBm8aq/2o/zV00jvOX/w= X-Received: from surenb-desktop.mtv.corp.google.com ([2620:15c:211:200:1bfc:e7ee:6530:4449]) (user=surenb job=sendgmr) by 2002:a81:9e53:0:b0:340:8556:472d with SMTP id n19-20020a819e53000000b003408556472dmr23620124ywj.197.1662053720792; Thu, 01 Sep 2022 10:35:20 -0700 (PDT) Date: Thu, 1 Sep 2022 10:34:48 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.37.2.789.g6183377224-goog Message-ID: <20220901173516.702122-1-surenb@google.com> Subject: [RFC PATCH RESEND 00/28] per-VMA locks proposal From: Suren Baghdasaryan To: akpm@linux-foundation.org Cc: michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, surenb@google.com, kernel-team@android.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220901_103524_708467_2322F03B X-CRM114-Status: GOOD ( 18.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org UmVzZW5kaW5nIHRvIGZpeCB0aGUgaXNzdWUgd2l0aCB0aGUgSW4tUmVwbHktVG8gdGFnIGluIHRo ZSBvcmlnaW5hbApzdWJtaXNzaW9uIGF0IFs0XS4KClRoaXMgaXMgYSBwcm9vZiBvZiBjb25jZXB0 IGZvciBwZXItdm1hIGxvY2tzIGlkZWEgdGhhdCB3YXMgZGlzY3Vzc2VkCmR1cmluZyBTUEYgWzFd IGRpc2N1c3Npb24gYXQgTFNGL01NIHRoaXMgeWVhciBbMl0sIHdoaWNoIGNvbmNsdWRlZCB3aXRo CnN1Z2dlc3Rpb24gdGhhdCDigJxhIHJlYWRlci93cml0ZXIgc2VtYXBob3JlIGNvdWxkIGJlIHB1 dCBpbnRvIHRoZSBWTUEKaXRzZWxmOyB0aGF0IHdvdWxkIGhhdmUgdGhlIGVmZmVjdCBvZiB1c2lu ZyB0aGUgVk1BIGFzIGEgc29ydCBvZiByYW5nZQpsb2NrLiBUaGVyZSB3b3VsZCBzdGlsbCBiZSBj b250ZW50aW9uIGF0IHRoZSBWTUEgbGV2ZWwsIGJ1dCBpdCB3b3VsZCBiZSBhbgppbXByb3ZlbWVu dC7igJ0gVGhpcyBwYXRjaHNldCBpbXBsZW1lbnRzIHRoaXMgc3VnZ2VzdGVkIGFwcHJvYWNoLgoK V2hlbiBoYW5kbGluZyBwYWdlIGZhdWx0cyB3ZSBsb29rdXAgdGhlIFZNQSB0aGF0IGNvbnRhaW5z IHRoZSBmYXVsdGluZwpwYWdlIHVuZGVyIFJDVSBwcm90ZWN0aW9uIGFuZCB0cnkgdG8gYWNxdWly ZSBpdHMgbG9jay4gSWYgdGhhdCBmYWlscyB3ZQpmYWxsIGJhY2sgdG8gdXNpbmcgbW1hcF9sb2Nr LCBzaW1pbGFyIHRvIGhvdyBTUEYgaGFuZGxlZCB0aGlzIHNpdHVhdGlvbi4KCk9uZSBub3RhYmxl IHdheSB0aGUgaW1wbGVtZW50YXRpb24gZGV2aWF0ZXMgZnJvbSB0aGUgcHJvcG9zYWwgaXMgdGhl IHdheQpWTUFzIGFyZSBtYXJrZWQgYXMgbG9ja2VkLiBCZWNhdXNlIGR1cmluZyBzb21lIG9mIG1t IHVwZGF0ZXMgbXVsdGlwbGUKVk1BcyBuZWVkIHRvIGJlIGxvY2tlZCB1bnRpbCB0aGUgZW5kIG9m IHRoZSB1cGRhdGUgKGUuZy4gdm1hX21lcmdlLApzcGxpdF92bWEsIGV0YykuIFRyYWNraW5nIGFs bCB0aGUgbG9ja2VkIFZNQXMsIGF2b2lkaW5nIHJlY3Vyc2l2ZSBsb2NrcwphbmQgb3RoZXIgY29t cGxpY2F0aW9ucyB3b3VsZCBtYWtlIHRoZSBjb2RlIG1vcmUgY29tcGxleC4gVGhlcmVmb3JlIHdl CnByb3ZpZGUgYSB3YXkgdG8gIm1hcmsiIFZNQXMgYXMgbG9ja2VkIGFuZCB0aGVuIHVubWFyayBh bGwgbG9ja2VkIFZNQXMKYWxsIGF0IG9uY2UuIFRoaXMgaXMgZG9uZSB1c2luZyB0d28gc2VxdWVu Y2UgbnVtYmVycyAtIG9uZSBpbiB0aGUKdm1fYXJlYV9zdHJ1Y3QgYW5kIG9uZSBpbiB0aGUgbW1f c3RydWN0LiBWTUEgaXMgY29uc2lkZXJlZCBsb2NrZWQgd2hlbgp0aGVzZSBzZXF1ZW5jZSBudW1i ZXJzIGFyZSBlcXVhbC4gVG8gbWFyayBhIFZNQSBhcyBsb2NrZWQgd2Ugc2V0IHRoZQpzZXF1ZW5j ZSBudW1iZXIgaW4gdm1fYXJlYV9zdHJ1Y3QgdG8gYmUgZXF1YWwgdG8gdGhlIHNlcXVlbmNlIG51 bWJlcgppbiBtbV9zdHJ1Y3QuIFRvIHVubG9jayBhbGwgVk1BcyB3ZSBpbmNyZW1lbnQgbW1fc3Ry dWN0J3Mgc2VxIG51bWJlci4KVGhpcyBhbGxvd3MgZm9yIGFuIGVmZmljaWVudCB3YXkgdG8gdHJh Y2sgbG9ja2VkIFZNQXMgYW5kIHRvIGRyb3AgdGhlCmxvY2tzIG9uIGFsbCBWTUFzIGF0IHRoZSBl bmQgb2YgdGhlIHVwZGF0ZS4KClRoZSBwYXRjaHNldCBpbXBsZW1lbnRzIHBlci1WTUEgbG9ja2lu ZyBvbmx5IGZvciBhbm9ueW1vdXMgcGFnZXMgd2hpY2gKYXJlIG5vdCBpbiBzd2FwLiBJZiB0aGUg aW5pdGlhbCBwcm9wb3NhbCBpcyBjb25zaWRlcmVkIGFjY2VwdGFibGUsIHRoZW4Kc3VwcG9ydCBm b3Igc3dhcHBlZCBhbmQgZmlsZS1iYWNrZWQgcGFnZSBmYXVsdHMgd2lsbCBiZSBhZGRlZC4KClBl cmZvcm1hbmNlIGJlbmNobWFya3Mgc2hvdyBzaW1pbGFyIGFsdGhvdWdoIHNsaWdodGx5IHNtYWxs ZXIgYmVuZWZpdHMgYXMKd2l0aCBTUEYgcGF0Y2hzZXQgKH43NSUgb2YgU1BGIGJlbmVmaXRzKS4g U3RpbGwsIHdpdGggbG93ZXIgY29tcGxleGl0eQp0aGlzIGFwcHJvYWNoIG1pZ2h0IGJlIG1vcmUg ZGVzaXJhYmxlLgoKVGhlIHBhdGNoc2V0IGFwcGxpZXMgY2xlYW5seSBvdmVyIDYuMC1yYzMKVGhl IHRyZWUgZm9yIHRlc3RpbmcgaXMgcG9zdGVkIGF0IFszXQoKWzFdIGh0dHBzOi8vbG9yZS5rZXJu ZWwub3JnL2FsbC8yMDIyMDEyODEzMTAwNi42NzcxMi0xLW1pY2hlbEBsZXNwaW5hc3NlLm9yZy8K WzJdIGh0dHBzOi8vbHduLm5ldC9BcnRpY2xlcy84OTM5MDYvClszXSBodHRwczovL2dpdGh1Yi5j b20vc3VyZW5iYWdoZGFzYXJ5YW4vbGludXgvdHJlZS9wZXJfdm1hX2xvY2tfcmZjCls0XSBodHRw czovL2xvcmUua2VybmVsLm9yZy9hbGwvMjAyMjA4MjkyMTI1MzEuMzE4NDg1Ni0xLXN1cmVuYkBn b29nbGUuY29tLwoKTGF1cmVudCBEdWZvdXIgKDIpOgogIHBvd2VyYy9tbTogdHJ5IFZNQSBsb2Nr LWJhc2VkIHBhZ2UgZmF1bHQgaGFuZGxpbmcgZmlyc3QKICBwb3dlcnBjL21tOiBkZWZpbmUgQVJD SF9TVVBQT1JUU19QRVJfVk1BX0xPQ0sKCk1pY2hlbCBMZXNwaW5hc3NlICgxKToKICBtbTogcmN1 IHNhZmUgVk1BIGZyZWVpbmcKClN1cmVuIEJhZ2hkYXNhcnlhbiAoMjUpOgogIG1tOiBpbnRyb2R1 Y2UgQ09ORklHX1BFUl9WTUFfTE9DSwogIG1tOiBpbnRyb2R1Y2UgX19maW5kX3ZtYSB0byBiZSB1 c2VkIHdpdGhvdXQgbW1hcF9sb2NrIHByb3RlY3Rpb24KICBtbTogbW92ZSBtbWFwX2xvY2sgYXNz ZXJ0IGZ1bmN0aW9uIGRlZmluaXRpb25zCiAgbW06IGFkZCBwZXItVk1BIGxvY2sgYW5kIGhlbHBl ciBmdW5jdGlvbnMgdG8gY29udHJvbCBpdAogIG1tOiBtYXJrIFZNQSBhcyBsb2NrZWQgd2hlbmV2 ZXIgdm1hLT52bV9mbGFncyBhcmUgbW9kaWZpZWQKICBrZXJuZWwvZm9yazogbWFyayBWTUFzIGFz IGxvY2tlZCBiZWZvcmUgY29weWluZyBwYWdlcyBkdXJpbmcgZm9yawogIG1tL2todWdlcGFnZWQ6 IG1hcmsgVk1BIGFzIGxvY2tlZCB3aGlsZSBjb2xsYXBzaW5nIGEgaHVnZXBhZ2UKICBtbS9tZW1w b2xpY3k6IG1hcmsgVk1BIGFzIGxvY2tlZCB3aGVuIGNoYW5naW5nIHByb3RlY3Rpb24gcG9saWN5 CiAgbW0vbW1hcDogbWFyayBWTUFzIGFzIGxvY2tlZCBpbiB2bWFfYWRqdXN0CiAgbW0vbW1hcDog bWFyayBWTUFzIGFzIGxvY2tlZCBiZWZvcmUgbWVyZ2luZyBvciBzcGxpdHRpbmcgdGhlbQogIG1t L21yZW1hcDogbWFyayBWTUEgYXMgbG9ja2VkIHdoaWxlIHJlbWFwcGluZyBpdCB0byBhIG5ldyBh ZGRyZXNzCiAgICByYW5nZQogIG1tOiBjb25kaXRpb25hbGx5IG1hcmsgVk1BIGFzIGxvY2tlZCBp biBmcmVlX3BndGFibGVzIGFuZAogICAgdW5tYXBfcGFnZV9yYW5nZQogIG1tOiBtYXJrIFZNQXMg YXMgbG9ja2VkIGJlZm9yZSBpc29sYXRpbmcgdGhlbQogIG1tL21tYXA6IG1hcmsgYWRqYWNlbnQg Vk1BcyBhcyBsb2NrZWQgaWYgdGhleSBjYW4gZ3JvdyBpbnRvIHVubWFwcGVkCiAgICBhcmVhCiAg a2VybmVsL2Zvcms6IGFzc2VydCBubyBWTUEgcmVhZGVycyBkdXJpbmcgaXRzIGRlc3RydWN0aW9u CiAgbW0vbW1hcDogcHJldmVudCBwYWdlZmF1bHQgaGFuZGxlciBmcm9tIHJhY2luZyB3aXRoIG1t dV9ub3RpZmllcgogICAgcmVnaXN0cmF0aW9uCiAgbW06IGFkZCBGQVVMVF9GTEFHX1ZNQV9MT0NL IGZsYWcKICBtbTogZGlzYWxsb3cgZG9fc3dhcF9wYWdlIHRvIGhhbmRsZSBwYWdlIGZhdWx0cyB1 bmRlciBWTUEgbG9jawogIG1tOiBpbnRyb2R1Y2UgcGVyLVZNQSBsb2NrIHN0YXRpc3RpY3MKICBt bTogaW50cm9kdWNlIGZpbmRfYW5kX2xvY2tfYW5vbl92bWEgdG8gYmUgdXNlZCBmcm9tIGFyY2gt c3BlY2lmaWMKICAgIGNvZGUKICB4ODYvbW06IHRyeSBWTUEgbG9jay1iYXNlZCBwYWdlIGZhdWx0 IGhhbmRsaW5nIGZpcnN0CiAgeDg2L21tOiBkZWZpbmUgQVJDSF9TVVBQT1JUU19QRVJfVk1BX0xP Q0sKICBhcm02NC9tbTogdHJ5IFZNQSBsb2NrLWJhc2VkIHBhZ2UgZmF1bHQgaGFuZGxpbmcgZmly c3QKICBhcm02NC9tbTogZGVmaW5lIEFSQ0hfU1VQUE9SVFNfUEVSX1ZNQV9MT0NLCiAga2VybmVs L2Zvcms6IHRocm90dGxlIGNhbGxfcmN1KCkgY2FsbHMgaW4gdm1fYXJlYV9mcmVlCgogYXJjaC9h cm02NC9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgfCAgIDEgKwogYXJjaC9hcm02NC9tbS9m YXVsdC5jICAgICAgICAgICAgICAgICAgfCAgMzYgKysrKysrKysrCiBhcmNoL3Bvd2VycGMvbW0v ZmF1bHQuYyAgICAgICAgICAgICAgICB8ICA0MSArKysrKysrKysrCiBhcmNoL3Bvd2VycGMvcGxh dGZvcm1zL3Bvd2VybnYvS2NvbmZpZyB8ICAgMSArCiBhcmNoL3Bvd2VycGMvcGxhdGZvcm1zL3Bz ZXJpZXMvS2NvbmZpZyB8ICAgMSArCiBhcmNoL3g4Ni9LY29uZmlnICAgICAgICAgICAgICAgICAg ICAgICB8ICAgMSArCiBhcmNoL3g4Ni9tbS9mYXVsdC5jICAgICAgICAgICAgICAgICAgICB8ICAz NiArKysrKysrKysKIGRyaXZlcnMvZ3B1L2RybS9pOTE1L2k5MTVfZ3B1X2Vycm9yLmMgIHwgICA0 ICstCiBmcy9wcm9jL3Rhc2tfbW11LmMgICAgICAgICAgICAgICAgICAgICB8ICAgMSArCiBmcy91 c2VyZmF1bHRmZC5jICAgICAgICAgICAgICAgICAgICAgICB8ICAgNiArKwogaW5jbHVkZS9saW51 eC9tbS5oICAgICAgICAgICAgICAgICAgICAgfCAxMDQgKysrKysrKysrKysrKysrKysrKysrKysr LQogaW5jbHVkZS9saW51eC9tbV90eXBlcy5oICAgICAgICAgICAgICAgfCAgMzMgKysrKysrLS0K IGluY2x1ZGUvbGludXgvbW1hcF9sb2NrLmggICAgICAgICAgICAgIHwgIDM3ICsrKysrKy0tLQog aW5jbHVkZS9saW51eC92bV9ldmVudF9pdGVtLmggICAgICAgICAgfCAgIDYgKysKIGluY2x1ZGUv bGludXgvdm1zdGF0LmggICAgICAgICAgICAgICAgIHwgICA2ICsrCiBrZXJuZWwvZm9yay5jICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICA3NSArKysrKysrKysrKysrKysrKy0KIG1tL0tjb25m aWcgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDEzICsrKysKIG1tL0tjb25maWcuZGVi dWcgICAgICAgICAgICAgICAgICAgICAgIHwgICA4ICsrCiBtbS9pbml0LW1tLmMgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgNiArKwogbW0vaW50ZXJuYWwuaCAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgIDQgKy0KIG1tL2todWdlcGFnZWQuYyAgICAgICAgICAgICAgICAgICAgICAg IHwgICAxICsKIG1tL21hZHZpc2UuYyAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAxICsK IG1tL21lbW9yeS5jICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDgyICsrKysrKysrKysr KysrKystLS0KIG1tL21lbXBvbGljeS5jICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA2ICst CiBtbS9tbG9jay5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMiArCiBtbS9tbWFw LmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICA2MCArKysrKysrKysrLS0tLQogbW0v bXByb3RlY3QuYyAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEgKwogbW0vbXJlbWFwLmMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDEgKwogbW0vbm9tbXUuYyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgIDIgKwogbW0vb29tX2tpbGwuYyAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgIDMgKy0KIG1tL3Ztc3RhdC5jICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICA2ICsrCiAzMSBmaWxlcyBjaGFuZ2VkLCA1MzEgaW5zZXJ0aW9ucygrKSwgNTQgZGVsZXRp b25zKC0pCgotLSAKMi4zNy4yLjc4OS5nNjE4MzM3NzIyNC1nb29nCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5n IGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5p bmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=