Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp5335422imb; Thu, 7 Mar 2019 13:13:16 -0800 (PST) X-Google-Smtp-Source: APXvYqwy1HWJQinixf5KcRCR+IlY/7Ny6BmuBnmbcQkYSN6xk4CFLZhHsYgbnoh7sSkyb/UgRT34 X-Received: by 2002:a17:902:2884:: with SMTP id f4mr14283678plb.203.1551993196245; Thu, 07 Mar 2019 13:13:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551993196; cv=none; d=google.com; s=arc-20160816; b=Io4vJbkhnfIwBuwnSA940FJE4Uq6Rq2OSj9TqqfuOZ6+3qNTkFC0ayK7zQTbD1vJOn kIC9HH1+jjwUZ6B1/DWCaLppgTSq/GcFJUaPN/R1er+1T7uJmZpnR4DwN1BRonUXRb5u 3kF49b13sDDJ4I8clLpd6RXUX8jAdHtT7j9wuKpj/8BwBq8+bYRp7x2hXbJv5bzQTPSq R1tbAzUpPnSTPJZHWeb97WCUNjL40hX2jmryZLGyaI6v/JjtSMqbDqFrYBsngdYVBR/e 20HN9huOuBGm6op+fjzzAIB5MdC0Y8AMnhJ7pUJOFW9LXGgK+BZVZc9I3HU1hMQuY+ZK Tnew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=YZGcEdzI6yFT9z5i+ij7BvlkOK4yLoKhr9sL8DhOvvM=; b=sgvnKRFwetI6ie9Nhw4Iys1c1s9wmlVvsQaPwjrdA6U2zSaMsWhf84dopkrANGwNMu I6ZDBW/hVrUWWAR20+baD+oWulVBYn5HeQxFkSC5DOTzzgmDLc6DUZt6cfacqwc8EEsS LA/7mnZnVGzr8uyEuak7f/Lj1x0sruuMCwGs8GyG3VaLd1jeRPEkIQXZyFTkVd5/VDqW qwU0yAgdAHkDYgJU2eCyD06MXTZRn/cMS+GM9218w08I04TNqsAqbanGST/nIQfqa9qR gdQCzETYxWYf7xiVQ80s1IxjYaPxyTeiaWt8FH+9u07WdFj8wJg9LS6i30OcUImQ/UrI kzhA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=zP387wsQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 128si5148790pfd.19.2019.03.07.13.13.00; Thu, 07 Mar 2019 13:13:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=zP387wsQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726364AbfCGVMd (ORCPT + 99 others); Thu, 7 Mar 2019 16:12:33 -0500 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:56667 "EHLO wout2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726186AbfCGVMa (ORCPT ); Thu, 7 Mar 2019 16:12:30 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A49923026; Thu, 7 Mar 2019 16:12:29 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 07 Mar 2019 16:12:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=YZGcEdzI6yFT9z5i+ij7BvlkOK4yLoKhr9sL8DhOvvM=; b=zP387wsQ iwB2Pj5oNg4P6RbCtq6r2w3NDmqeULhnnolFNcYtIWP22H+68MFMErEqoAzOhQfe PU3ZdOBcUKlcTMvUSrbGn0ajR83uGSGq9Pg+XlpazZ5CctYqDzA/rqPiONMg4gi+ DvXhH4rcbFr7u2VN/WSqKOl+VcpoQtVaaz8Iw1d70KjyB84rQ9WYU0t2lP8S+q0b 4KBVRBNauzx/JSwYzOZv5uJ/Lz0uQC3kHnpEuRI6L/GiXyX6A1nHJyiLd3jSD27w aP76+1I5KyPOB760UbCXNonfUEpqDkEWt6Iqv9JbviVzDj2XzQwrd62rix+rXg2V rKWSqAGUhcDUNw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeekgdduhedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpedfvfhosghi nhcuvedrucfjrghrughinhhgfdcuoehtohgsihhnsehkvghrnhgvlhdrohhrgheqnecukf hppeduvdegrdduieelrdehrdduheeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehtohgs ihhnsehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedu X-ME-Proxy: Received: from eros.localdomain (124-169-5-158.dyn.iinet.net.au [124.169.5.158]) by mail.messagingengine.com (Postfix) with ESMTPA id 4F77E10331; Thu, 7 Mar 2019 16:12:26 -0500 (EST) From: "Tobin C. Harding" To: Jonathan Corbet Cc: "Tobin C. Harding" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 3/9] docs: Remove unnecessary reference link title Date: Fri, 8 Mar 2019 08:11:47 +1100 Message-Id: <20190307211153.28400-4-tobin@kernel.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190307211153.28400-1-tobin@kernel.org> References: <20190307211153.28400-1-tobin@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Labels that precede a heading use the heading as the link title. Explicitly adding the link title defeats the purpose of this feature i.e. makes the reference less maintainable. Remove unnecessary reference link title. Signed-off-by: Tobin C. Harding --- Documentation/admin-guide/mm/numa_memory_policy.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/mm/numa_memory_policy.rst b/Documentation/admin-guide/mm/numa_memory_policy.rst index d78c5b315f72..1ef0146eaa4d 100644 --- a/Documentation/admin-guide/mm/numa_memory_policy.rst +++ b/Documentation/admin-guide/mm/numa_memory_policy.rst @@ -20,8 +20,7 @@ which is an administrative mechanism for restricting the nodes from which memory may be allocated by a set of processes. Memory policies are a programming interface that a NUMA-aware application can take advantage of. When both cpusets and policies are applied to a task, the restrictions of the cpuset -takes priority. See :ref:`Memory Policies and cpusets ` -below for more details. +takes priority. See :ref:`mem_pol_and_cpusets` below for more details. Memory Policy Concepts ====================== @@ -56,7 +55,7 @@ Task/Process Policy [clone() w/o the CLONE_VM flag] and exec*(). This allows a parent task to establish the task policy for a child task exec()'d from an executable image that has no awareness of memory policy. See the - :ref:`Memory Policy APIs ` section, + :ref:`memory_policy_apis` section, below, for an overview of the system call that a task may use to set/change its task/process policy. @@ -77,7 +76,7 @@ VMA Policy A "VMA" or "Virtual Memory Area" refers to a range of a task's virtual address space. A task may define a specific policy for a range of its virtual address space. See the - :ref:`Memory Policy APIs ` section, + :ref:`memory_policy_apis` section, below, for an overview of the mbind() system call used to set a VMA policy. @@ -142,7 +141,7 @@ Shared Policy Although hugetlbfs segments now support lazy allocation, their support for shared policy has not been completed. - As mentioned above in :ref:`VMA policies ` section, + As mentioned above in :ref:`vma_policy` section, allocations of page cache pages for regular files mmap()ed with MAP_SHARED ignore any VMA policy installed on the virtual address range backed by the shared file mapping. Rather, -- 2.21.0