From patchwork Wed Dec 5 02:34:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wei Yang X-Patchwork-Id: 10712909 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9DDD213BF for ; Wed, 5 Dec 2018 02:35:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8BAA02C95D for ; Wed, 5 Dec 2018 02:35:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7D4E52CB42; Wed, 5 Dec 2018 02:35:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1183B2C95D for ; Wed, 5 Dec 2018 02:35:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 453B96B71FD; Tue, 4 Dec 2018 21:35:27 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 402B36B71FE; Tue, 4 Dec 2018 21:35:27 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F48E6B71FF; Tue, 4 Dec 2018 21:35:27 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by kanga.kvack.org (Postfix) with ESMTP id E37D56B71FD for ; Tue, 4 Dec 2018 21:35:26 -0500 (EST) Received: by mail-pf1-f200.google.com with SMTP id q64so15589282pfa.18 for ; Tue, 04 Dec 2018 18:35:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:from:to:cc:subject:date :message-id; bh=byW6p4S4eM51fSS1xfZ9xzVN+oqvY4pZ3OBeX/tNsqM=; b=cYGf2+q78Gce6N++QGSL0N8bO1Fndg/qkdS3vECbLx7Os0UBYkdKMubFWFMiCJ0Vzl 7PVipL1uk3H9jLhbSPRXupxN/UnJTcDbtq7Y1EkulIcT1DHFaFYmg3j7Y8jNtZ1Knqbi XdP+QIns6cV/GBWewcXTDw+aPubcGZ8MdPXUuQBtDtuXuaqNh6UzkTmDbvR9ie6urzO5 fBX1oyZGP5tnn4/U2v0lmN/rVIh3MhhWjjhZmRXXL0loI2Lkpr3YiEEECRdK5m9BEOuT 0KPIesSDTHzFfPOMkN/RwN5AP1Qo0kk5bGlGm7C8nKiZtAO0gCzFNsYBUik7oSt6xIVH sAmw== X-Gm-Message-State: AA+aEWZQ+wZTHPO9zQX8+GrlOnBWuls/yq0xVnxR2qAAJX9uq91w7mTQ JMP73wMXh8oFDB8d+n7+lHoyzdk70Y4yRDTGiUbm25XjJNbVEUK+F0pDwvKoBxhOkEBfA7if3FD d9krFTPPhgyuqS82r4JVGtamHy6x2Sc41FYAelNBIN9xrJGnX8nAZznAXWhtkPWITvkJEUA90lZ kfxsWxJBHyRr8bt/QrpbTUz7zhEN+QkJ3uXNJQfMavrjycGJh6pKTvBE2Osl8VSNUdw/V2tuA2o cz2H5vU5A2vcZ8XXWfwJVea2HEwCC/P7pV2Z4JuQ3AsyJyWsPjWu1whds3pk5BIfSaQmwMGE/u7 thloKdQSiGkYxEJf8JuxiiYhxpHnTrJD0BHmRM7sE5J4QM5mBxw0icJ5Y8H++oEbQsKx9Motna3 G X-Received: by 2002:a17:902:24e7:: with SMTP id l36mr10819659plg.61.1543977326521; Tue, 04 Dec 2018 18:35:26 -0800 (PST) X-Received: by 2002:a17:902:24e7:: with SMTP id l36mr10819605plg.61.1543977325642; Tue, 04 Dec 2018 18:35:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543977325; cv=none; d=google.com; s=arc-20160816; b=zTegkzU3/7UWPIslMzCUhij7isYWw+929JHQNlpcHzWaaXiFg6uCyCj1ccmLtjq8Wy +f9fhj0Z7OBwHEqT4gZYWM7PLmjFtsi+4gbrHcB0/QkFIL29qbAFGXHSlfPkNdn9Mn1a siE7XyEmaLWY20WgJd7D5uVELLklWugZT5NWsfdPoj904aDV2DORuMKTvqwzr2b9xUBA 2EwoRvIh0Fgz1Puf4au7QmdsoV9V2tBxkuqmx3FToB2GeZi6EV8fsX8/ugkOnZiXl0rr rogM5EfUeyE+L5O3zyhpCzKMjvuV+1RW1z+dfwmVpew1QcKIMkrTOOtkskne0eQzWZNi BkMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from:dkim-signature; bh=byW6p4S4eM51fSS1xfZ9xzVN+oqvY4pZ3OBeX/tNsqM=; b=zGngfDhcejD2GnsO6MGrE/Yhn0+svvamQWTkiaW1LQUBUFxNsQrpbrkjLbwxU3cCp/ 82R+tcKXUrPPkj7i+wH7zve0GgRcy4yKajfVzRw/vm+QPz2fhbtC+blmcpRsfLsGgc28 lPex6zAvBDGdElNwdXsIKulypzWILGTpVlbJ29PygocJhzGBjeedYuyPlh3tEIl2q5pE F/c7ZCDGZWZByFOF0vyfD+Jc9M90n91DA9xJVKgf8H77qQSGIVyeZzSY4ujXytyymJE0 +TqCxyjkt0dR9LyEGMmuRAE4OSBX6QgFvRB7x2GRQ/lhcwxiss600h6rJL7cFtqP0QO3 8ahA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ATrCFX0A; spf=pass (google.com: domain of richard.weiyang@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id 24sor23920910pgq.13.2018.12.04.18.35.25 for (Google Transport Security); Tue, 04 Dec 2018 18:35:25 -0800 (PST) Received-SPF: pass (google.com: domain of richard.weiyang@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ATrCFX0A; spf=pass (google.com: domain of richard.weiyang@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=byW6p4S4eM51fSS1xfZ9xzVN+oqvY4pZ3OBeX/tNsqM=; b=ATrCFX0AUw3N/t6K+D+lC4nB4fmUsKeq1RFks/SpheQPpkjHC6Z6CVITWp++RH2gdi bhuO2LU5WwxohVR983/iYAhPARSEcMbe/1NywaUFmz2I+Q5+LCrS1u6Zcx319/nyUbKD Rvq9/glWewozLqQvUXAoMF9eMq1ov4Kwgc5VxCb7PnO6zL5rMySEb/MB9Oftw0sD9Cfj +nue9qyZbyEfBFatQTtGrSq40KdkZ73XecHRBRgpMpWMyvcL7d8UbdkAU1bxI+7vshuQ D5ZWYyUPzZd3i1lNMke7wIKSONnf5juC8wicTHD8DQdA05lFx2MWVeoy/mEVqerZnYaO PIPg== X-Google-Smtp-Source: AFSGD/VZ460ddkmSWsEb1ZtVrfS9y8Y9IMIzLwBgweXpFQGuJwDn1pNI83oEFnMYDXs/iW68Hcno5Q== X-Received: by 2002:a63:c10f:: with SMTP id w15mr18644758pgf.199.1543977325174; Tue, 04 Dec 2018 18:35:25 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id v9sm27454463pfg.144.2018.12.04.18.35.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 18:35:24 -0800 (PST) From: Wei Yang To: david@redhat.com, mhocko@suse.com, osalvador@suse.de Cc: akpm@linux-foundation.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, Wei Yang Subject: [PATCH 1/2] admin-guide/memory-hotplug.rst: remove locking internal part from admin-guide Date: Wed, 5 Dec 2018 10:34:25 +0800 Message-Id: <20181205023426.24029-1-richard.weiyang@gmail.com> X-Mailer: git-send-email 2.15.1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP Locking Internal section exists in core-api documentation, which is more suitable for this. This patch removes the duplication part here. Signed-off-by: Wei Yang Reviewed-by: David Hildenbrand Acked-by: Mike Rapoport --- Documentation/admin-guide/mm/memory-hotplug.rst | 40 ------------------------- 1 file changed, 40 deletions(-) diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index 5c4432c96c4b..241f4ce1e387 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -392,46 +392,6 @@ Need more implementation yet.... - Notification completion of remove works by OS to firmware. - Guard from remove if not yet. - -Locking Internals -================= - -When adding/removing memory that uses memory block devices (i.e. ordinary RAM), -the device_hotplug_lock should be held to: - -- synchronize against online/offline requests (e.g. via sysfs). This way, memory - block devices can only be accessed (.online/.state attributes) by user - space once memory has been fully added. And when removing memory, we - know nobody is in critical sections. -- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC) - -Especially, there is a possible lock inversion that is avoided using -device_hotplug_lock when adding memory and user space tries to online that -memory faster than expected: - -- device_online() will first take the device_lock(), followed by - mem_hotplug_lock -- add_memory_resource() will first take the mem_hotplug_lock, followed by - the device_lock() (while creating the devices, during bus_add_device()). - -As the device is visible to user space before taking the device_lock(), this -can result in a lock inversion. - -onlining/offlining of memory should be done via device_online()/ -device_offline() - to make sure it is properly synchronized to actions -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type) - -When adding/removing/onlining/offlining memory or adding/removing -heterogeneous/device memory, we should always hold the mem_hotplug_lock in -write mode to serialise memory hotplug (e.g. access to global/zone -variables). - -In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read -mode allows for a quite efficient get_online_mems/put_online_mems -implementation, so code accessing memory can protect from that memory -vanishing. - - Future Work =========== From patchwork Wed Dec 5 02:34:26 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wei Yang X-Patchwork-Id: 10712911 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6968F14E2 for ; Wed, 5 Dec 2018 02:35:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 593EE2C95D for ; Wed, 5 Dec 2018 02:35:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4CBBB2CB42; Wed, 5 Dec 2018 02:35:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A4B682C95D for ; Wed, 5 Dec 2018 02:35:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7B796B71F7; Tue, 4 Dec 2018 21:35:33 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id D2ADC6B71FE; Tue, 4 Dec 2018 21:35:33 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C40B16B71FF; Tue, 4 Dec 2018 21:35:33 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by kanga.kvack.org (Postfix) with ESMTP id 84F186B71F7 for ; Tue, 4 Dec 2018 21:35:33 -0500 (EST) Received: by mail-pg1-f199.google.com with SMTP id g188so10219014pgc.22 for ; Tue, 04 Dec 2018 18:35:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:from:to:cc:subject:date :message-id:in-reply-to:references; bh=OBRiPkArGg9pvbpKBjvwsW5lZXZ35bCeYSQi3SQgqaI=; b=b15uoiWsJVJoLyy52ICQ1MZpRDHGglh3FX2wzqLAkYjVS5eJ8CZ2NSRPIM07hgpBFU seEYORS8WRNxGRMm1a8bqdIn3+r6Y+MdvhCNzaarbu7Hem9a8RvF6ptRcOf7xYZArKyY KO8iqfH1eWkYbT5JvvfGNEKpTlKK+theqDAxY/9hXW0mCsiSUP3juhe5dAcZ+gj9cGD4 XhHpzfyYqX0F+tspKai1OT9xgsbgs6PE2tMrFqwJRAxu8XQJstprWy429m4No+59GL68 yxxJSgTvdJKZq7jEhHVmCg6Vw0L7/y8pmjCHZTCdQWJVMJdaRuhpQc0nkyviR418U2M+ zqdg== X-Gm-Message-State: AA+aEWYyHICpg37W2BGhNNoHb1C1Yt0B3Y5w7GFYIIG453xy/kaFk4In g8i8e6yA8hCe3D44hY1Oo7yC/9Iqx2qKCXu44Fccf3SRbC/27c4lzW8Bi3xVRtZCiLOP9R3UkBz 7UPP37w8h+qxi4EauMQ3nFvhOQtJp+jPa5aoCVG5XwaYscAGOQ7yxLcMsSGtxR6tzQM6S01YoX3 SD/cV9GFOIGLP8J9sASZytvA/zk7qBS3V6pW/XOU7UcbiMw2h6LIpZWjtD+Vf+OMrx2QRsvlEC0 Bd8Sj5OXeANFRUqFvEi6dASt2mTFk0iw8ExEZQOyURlqyVbG/4lmF8umpa5L38iKzwVO6ejNs0L daE+K/SPD1wn7ABHmNlK0oMFXWJA2EejcDNnv3bqzp6tWcNWVAsTJS4oe+Wd94y2oSZQ3y9+gua K X-Received: by 2002:a17:902:2904:: with SMTP id g4mr22272080plb.39.1543977333206; Tue, 04 Dec 2018 18:35:33 -0800 (PST) X-Received: by 2002:a17:902:2904:: with SMTP id g4mr22272035plb.39.1543977332411; Tue, 04 Dec 2018 18:35:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543977332; cv=none; d=google.com; s=arc-20160816; b=wHzGur8lRVKRb9UjlhA9jOOCXtT2JOce4TpyMnwDFRi+kWNsgp2kdNCiOKOoQVtGvc VNDqPhk6aaazOcJn88WLRGD0WnGNB5aBEN5NSMM91wpi9x2XzaOTeSNw5/ppjtuDewfh wwA5DI45L6dLzccMfGFE1nMX7/MVGknZTbAzC6VUlIK/wR2weJbwWtiYbWE5Fq8WLAeu lw79QJjEwvFShtjrG8MMjLzCjj2HqeRQ3uy2s85l/4lBAHI7xzCMX4prVfqDk1/VrzB4 XN+6PykXWhSUOWkT56r0y5YS3k4AsNs3vvFi0gDPcxxptZYkLjOz1cnXI7p4c3yq6r+0 EVWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=OBRiPkArGg9pvbpKBjvwsW5lZXZ35bCeYSQi3SQgqaI=; b=zEH2NoHd1ZxK+P8AhGI3bIaRWPaKRKeLWJq9+ZpYJ+7qSh1XKkpZUjdZ1IxrjSw8fG u6HDYGlP41u4lvWeWARyGZ3sXFi0zS2nIMaPLOkPvdtLAWwFYi6xM62OT+xwTHi4EXqf EVCLym9Fcaj/bZRRLjzYHKXTK/NDVyZJdnuRNj7LoQCKuO3nAWOsQSLwvk4QphKrignT QZAuDnkwnAvnRF0sWyJeTq8nh9zk7m8r6ArWfQWIWVBUT5bhUOepqrJx6Mx5gj0AdJR9 5ysbLfBdWjmIcDiF9rV/aEgPvqm1lODuechUDkOkL6fQztQS7LsXyieFNzo7UztJ0ttp F1Pw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=R4aC+HRl; spf=pass (google.com: domain of richard.weiyang@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id f21sor24925599pgm.40.2018.12.04.18.35.32 for (Google Transport Security); Tue, 04 Dec 2018 18:35:32 -0800 (PST) Received-SPF: pass (google.com: domain of richard.weiyang@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=R4aC+HRl; spf=pass (google.com: domain of richard.weiyang@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=OBRiPkArGg9pvbpKBjvwsW5lZXZ35bCeYSQi3SQgqaI=; b=R4aC+HRl1fc9MgkD1Sqi+zkuZojGWX9XieTDI3ljT9Y2Vyg1TsMyv1W7BrQalQ/2ao 8cMk2FjFxyZ+QgUngrRu3Og/wTXui+/lEx3IYvGLbeYnjlM1nmnf3vBUidBs208fxdwB whUysH+sLKOuJa6Q/Ci2RhjagPpb6/qXKwLrQ9+7k+hmEH6AaizixK64P3s0ADUnb20j ORoY02R5vwU5xDFxFpYio2COHTziOb8pwJ14u4RF5x5vgAP2v54OxS23x4Nm9czz2HrQ pcSa1jBCoyn3HweiBFq2AEjSX3elJdHVVR1aqNaKPoyl/Is0n6kb2xyti8kn/bEwpMzO O5gQ== X-Google-Smtp-Source: AFSGD/X4u6RzQJ0hbVoIKgY2Y4Not5sn8w0uiDD5wtxwcz5ONMsqmC95RWdJ1mpelqg/t33simEYpw== X-Received: by 2002:a65:6542:: with SMTP id a2mr18753013pgw.389.1543977332056; Tue, 04 Dec 2018 18:35:32 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id i123sm35791186pfg.164.2018.12.04.18.35.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 18:35:31 -0800 (PST) From: Wei Yang To: david@redhat.com, mhocko@suse.com, osalvador@suse.de Cc: akpm@linux-foundation.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, Wei Yang Subject: [PATCH 2/2] core-api/memory-hotplug.rst: divide Locking Internal section by different locks Date: Wed, 5 Dec 2018 10:34:26 +0800 Message-Id: <20181205023426.24029-2-richard.weiyang@gmail.com> X-Mailer: git-send-email 2.15.1 In-Reply-To: <20181205023426.24029-1-richard.weiyang@gmail.com> References: <20181205023426.24029-1-richard.weiyang@gmail.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP Currently locking for memory hotplug is a little complicated. Generally speaking, we leverage the two global lock: * device_hotplug_lock * mem_hotplug_lock to serialise the process. While for the long term, we are willing to have more fine-grained lock to provide higher scalability. This patch divides Locking Internal section based on these two global locks to help readers to understand it. Also it adds some new finding to enrich it. [David: words arrangement] Signed-off-by: Wei Yang --- Documentation/core-api/memory-hotplug.rst | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/Documentation/core-api/memory-hotplug.rst b/Documentation/core-api/memory-hotplug.rst index de7467e48067..95662b283328 100644 --- a/Documentation/core-api/memory-hotplug.rst +++ b/Documentation/core-api/memory-hotplug.rst @@ -89,6 +89,20 @@ NOTIFY_STOP stops further processing of the notification queue. Locking Internals ================= +There are three locks involved in memory-hotplug, two global lock and one local +lock: + +- device_hotplug_lock +- mem_hotplug_lock +- device_lock + +Currently, they are twisted together for all kinds of reasons. The following +part is divided into device_hotplug_lock and mem_hotplug_lock parts +respectively to describe those tricky situations. + +device_hotplug_lock +--------------------- + When adding/removing memory that uses memory block devices (i.e. ordinary RAM), the device_hotplug_lock should be held to: @@ -111,13 +125,20 @@ As the device is visible to user space before taking the device_lock(), this can result in a lock inversion. onlining/offlining of memory should be done via device_online()/ -device_offline() - to make sure it is properly synchronized to actions -via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type) +device_offline() - to make sure it is properly synchronized to actions via +sysfs. Even mem_hotplug_lock is used to protect the process, because of the +lock inversion described above, holding device_hotplug_lock is still advised +(to e.g. protect online_type) + +mem_hotplug_lock +--------------------- When adding/removing/onlining/offlining memory or adding/removing heterogeneous/device memory, we should always hold the mem_hotplug_lock in write mode to serialise memory hotplug (e.g. access to global/zone -variables). +variables). Currently, we take advantage of this to serialise sparsemem's +mem_section handling in sparse_add_one_section() and +sparse_remove_one_section(). In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read mode allows for a quite efficient get_online_mems/put_online_mems