Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3373725yba; Mon, 8 Apr 2019 17:48:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqxVD4QZrRTBhE7smA+shsH/Y69xFsGc6K2pjKtH3cY5f33GW9l7YxP+wKXsQXEyKLEq1eLF X-Received: by 2002:a62:6f47:: with SMTP id k68mr17110805pfc.196.1554770896887; Mon, 08 Apr 2019 17:48:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554770896; cv=none; d=google.com; s=arc-20160816; b=bbpZ75sPpJ2rfqCPagLdYHn0pi6Pm3E6Yx/f0h3nuvq0cwR7EzyBAvAHJmZlgm0RGH 1LRadawMmFJYWakOmBhBEeg0VXjdCSXsGU7OPEgpW45PdDFaHcGfsIvwovsxaXO7ycFH Axnf25Y1hTU+XJQcWSYKdXroJK3Qqd2SYkHe4daLmDbQjYuqDHa8M+2ihI1Qg9kaPEZx UKn+t9+6guZkAKfWHsB0qdoe59CDfg45FME3KkZHk0Ct1yk3+Xv0CUY09YGMiVR25mcA +tZNV9aJLlKriaj1CdXJ9e3DicUMc7i2c5rzu4XrmKCug/xfSR+xhsXX/ji4hMBfVSI4 adIQ== 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=P0zNKeCy2JQLXV9pyaFfhRTUVfbqD8BKB8VBdzTrxlY=; b=kD19NeAhDWdTNtue6zRdS366YLJDWp6fPrEgWMjUYkCxTEK2LQ7PwsBOqkdl1ZKfeu 5zgUg1FNbXj5D6/ZAa21ivU66qdi9Ve6QvgWUxNSUnpId11yZjr14qXrIJOR9YfVO4zp /p8npo4k5EszkC6L+FSVhiA7PrxvZ8IP5w99fzu8UWryOIfrIUErsr+02doRIWWS1OJh QS+baDLSwFaa8xwyujszIivWXruTRGCUVoERlkRs8zgtrWv4IM1gW7Fts8VfQO4sdkPN KkOG2ts2CY8JfWf6SZscqGSNM9k4G+5bcsS6pEiTdUITpsetE3EQZR5qHykx+WppTyB+ OHAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=nHQmV9T9; 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 v16si27536857plo.33.2019.04.08.17.48.01; Mon, 08 Apr 2019 17:48:16 -0700 (PDT) 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=nHQmV9T9; 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 S1726851AbfDIAop (ORCPT + 99 others); Mon, 8 Apr 2019 20:44:45 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:55977 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726387AbfDIAom (ORCPT ); Mon, 8 Apr 2019 20:44:42 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1429123641; Mon, 8 Apr 2019 20:44:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 08 Apr 2019 20:44:41 -0400 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=P0zNKeCy2JQLXV9pyaFfhRTUVfbqD8BKB8VBdzTrxlY=; b=nHQmV9T9 GvTflNrcDKvm//OVkUZnOh0ey6ul8029Beep8Q/xRABkfr+f77r7fXZwzzib5D1J eiGAp8RQJI0w76tfGAOtFW030LTrHKaF+9OsVcuJpQ7g9+BlpA7vkbERszA5DSim UMS4YqVlM3evX64QZcaGHwe03dzlVFPXXHLmR3Jj25HWNyJQrVqSwsZ+nIuNz5X+ DiajorjAuc72wygBrHIfefRmcTSlkq6Wkf/xHQr2EDI3ACbGsECGFxH1Y3iA86uN TuXAcjKzY9cME2GV5m7RCTAqZ0XyaeG9PdN7x5QXTRLjXfTMmQBDUk3J1YKIHmHi kG1D3t5Pouqi+Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofgjfhgggfestdekredtredttdenucfhrhhomhepfdfvohgsihhn ucevrdcujfgrrhguihhnghdfuceothhosghinheskhgvrhhnvghlrdhorhhgqeenucfkph epuddvuddrgeegrddvudejrdehtdenucfrrghrrghmpehmrghilhhfrhhomhepthhosghi nheskhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from eros.localdomain (ppp121-44-217-50.bras1.syd2.internode.on.net [121.44.217.50]) by mail.messagingengine.com (Postfix) with ESMTPA id E5BF6E4482; Mon, 8 Apr 2019 20:44:38 -0400 (EDT) From: "Tobin C. Harding" To: Jonathan Corbet Cc: "Tobin C. Harding" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 3/4] docs: Remove unnecessary reference link title Date: Tue, 9 Apr 2019 10:43:58 +1000 Message-Id: <20190409004359.29668-4-tobin@kernel.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190409004359.29668-1-tobin@kernel.org> References: <20190409004359.29668-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 is redundant and makes the reference slightly 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