From patchwork Fri Aug 17 14:47:16 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 10568971 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 1B38C14BD for ; Fri, 17 Aug 2018 14:47:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0BF162BBF3 for ; Fri, 17 Aug 2018 14:47:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 004B62BC0C; Fri, 17 Aug 2018 14:47:44 +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=-2.9 required=2.0 tests=BAYES_00,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 3DA9F2BBF3 for ; Fri, 17 Aug 2018 14:47:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1976A6B08BE; Fri, 17 Aug 2018 10:47:43 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 123B16B08BF; Fri, 17 Aug 2018 10:47:43 -0400 (EDT) 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 00F0D6B08C0; Fri, 17 Aug 2018 10:47:42 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by kanga.kvack.org (Postfix) with ESMTP id BE72F6B08BF for ; Fri, 17 Aug 2018 10:47:42 -0400 (EDT) Received: by mail-oi0-f70.google.com with SMTP id u11-v6so7227516oif.22 for ; Fri, 17 Aug 2018 07:47:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:in-reply-to:references:message-id; bh=1nvKbnYy9V9R/8wICRdxrgN6fFE7TekHTLwTuMTYLPo=; b=ErhPuvIPLXGyrR3jhYsq2RlAfcsfgIQYIEjlhYZPVSP22VGB5MBBTpMkDJxO/liyWl 67/gCza/yWs9Rq7boWoXb98amy1Kkhq4auNF6cqugwDmuC7EIBMMgvKpg5MSf89Vzl0h ian7Qs85fwBHqvQ9SfkVYdQyuKfYcEAvHvMfSCkSd29O6gictq6eDEZQXmsV51dvCCj9 TGHWqtoJ8QAebZAr6dRuFfEElWaXP3P4Ax0ghqVjuv6PewEaAsmvTWGxKrZbHX8hb2TJ hJOflXpPpcgzke5SiNiyObMb+r7PHuQJ8V3GRAqlmRQzmtVluzT6Ef/etwUK7MxUo5WY PY5g== X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 148.163.156.1 is neither permitted nor denied by best guess record for domain of rppt@linux.vnet.ibm.com) smtp.mailfrom=rppt@linux.vnet.ibm.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com X-Gm-Message-State: AOUpUlF1pfBz0s9GDx5V2dTq210nM0lSOvFvpKsIrGv7X6RQBDFUMfkf bwuY3LqFoUjn7jLSxwBrvCeKKf5nk1GHWXCyS8uBaBMyIiGWQaiL3pUM6bmDQG7f6kxTbE90MDk XsKn0+J7BGDWrhHmLFWXSkwj7uReVv9owJINGOtzI6MuAfI8veblkp5IG6cs5Qn4= X-Received: by 2002:aca:56d7:: with SMTP id k206-v6mr3014988oib.106.1534517262502; Fri, 17 Aug 2018 07:47:42 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxMKDq2BvAZvnDf/q9ebfbt2uU2LZyC4bMejwBv3kEBD9tYBkJCEcYOdFjSC/kCGi9K3j+0 X-Received: by 2002:aca:56d7:: with SMTP id k206-v6mr3014905oib.106.1534517261356; Fri, 17 Aug 2018 07:47:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534517261; cv=none; d=google.com; s=arc-20160816; b=IgnRL1vI2csGH3jZVlQvXqsxjVs3omJSkMcjUaHMHW+rtVs5N3v8sT6Mc+WxvRsUUv o5F3qzc3v8+/NE7UF7QjSBRtFw4P0Wt5uL8yfuOjjwi8Vfam8+0AMaeVzmI9pTKsh8Y+ Z9Wduq/yW9UpFl1ijyutBOl/zEbTZGMD5zSOQHVPPcUsohi94pOXlQgxnU6WMelRXY7E w4M1QnXswVYzXh2E0LFN5SKujpZSetbm7ImYBEudFbchC50qJ8XKbAh68yhNvS2rZb1V J4rqrr8nIEYn/nuWNSNGXjYY6OhI2MrVWMM1WGSbLKeZNFcAzkzI8roCc0kCqnpODyPi RLSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:references:in-reply-to:date:subject:cc:to:from :arc-authentication-results; bh=1nvKbnYy9V9R/8wICRdxrgN6fFE7TekHTLwTuMTYLPo=; b=kJFvRZ7Crx7p77BRBxMYXjPrEkR9NzfD2Fh4xHsqLN2nBubqge0rJkyr4ftm3fBPlj Oc4ZE8qE/6HxWG4hjvLksHdAjR9C7mxz2EWnAeRCbYZz3TWR8iNFQVIrnAPph7FzYqpK r/VdzYYuM6i9Gbp8/+RjdS3WkpEIMkxFWQDmlHR8wbKIrv4FEQn9HwsxhvoioXnUBHYI xQVzzkcIkx2ctFpGXprh8VtPv2YxNYnOCRuntlLceFSnaZv+hPg/KD4Gg1vgthyhq0wH fcpMoF8tXFGhdegiIzJgpM6e6KlEuf9EQp4IvsXUNfNSeY/ducoRb/4I+KkcB/413twR XKrw== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 148.163.156.1 is neither permitted nor denied by best guess record for domain of rppt@linux.vnet.ibm.com) smtp.mailfrom=rppt@linux.vnet.ibm.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com. [148.163.156.1]) by mx.google.com with ESMTPS id b125-v6si1518618oia.69.2018.08.17.07.47.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 07:47:41 -0700 (PDT) Received-SPF: neutral (google.com: 148.163.156.1 is neither permitted nor denied by best guess record for domain of rppt@linux.vnet.ibm.com) client-ip=148.163.156.1; Authentication-Results: mx.google.com; spf=neutral (google.com: 148.163.156.1 is neither permitted nor denied by best guess record for domain of rppt@linux.vnet.ibm.com) smtp.mailfrom=rppt@linux.vnet.ibm.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7HEiB2w091028 for ; Fri, 17 Aug 2018 10:47:40 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0a-001b2d01.pphosted.com with ESMTP id 2kwyw519wg-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 17 Aug 2018 10:47:40 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 17 Aug 2018 15:47:35 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp01.uk.ibm.com (192.168.101.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 17 Aug 2018 15:47:32 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w7HElVwq34734260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 17 Aug 2018 14:47:31 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 08C3752051; Fri, 17 Aug 2018 17:47:34 +0100 (BST) Received: from rapoport-lnx (unknown [9.148.205.113]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTPS id F3DF65204E; Fri, 17 Aug 2018 17:47:31 +0100 (BST) Received: by rapoport-lnx (sSMTP sendmail emulation); Fri, 17 Aug 2018 17:47:28 +0300 From: Mike Rapoport To: Jonathan Corbet Cc: Michal Hocko , Randy Dunlap , Matthew Wilcox , Vlastimil Babka , linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport Subject: [PATCH v3 3/3] docs: core-api: add memory allocation guide Date: Fri, 17 Aug 2018 17:47:16 +0300 X-Mailer: git-send-email 2.7.4 In-Reply-To: <1534517236-16762-1-git-send-email-rppt@linux.vnet.ibm.com> References: <1534517236-16762-1-git-send-email-rppt@linux.vnet.ibm.com> X-TM-AS-GCONF: 00 x-cbid: 18081714-4275-0000-0000-000002AB3F51 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18081714-4276-0000-0000-000037B469A6 Message-Id: <1534517236-16762-4-git-send-email-rppt@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-17_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808170160 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 Signed-off-by: Mike Rapoport Acked-by: Michal Hocko Acked-by: Randy Dunlap --- Documentation/core-api/index.rst | 1 + Documentation/core-api/memory-allocation.rst | 124 +++++++++++++++++++++++++++ 2 files changed, 125 insertions(+) create mode 100644 Documentation/core-api/memory-allocation.rst diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index cdc2020..8afc0da 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -27,6 +27,7 @@ Core utilities errseq printk-formats circular-buffers + memory-allocation mm-api gfp_mask-from-fs-io timekeeping diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst new file mode 100644 index 0000000..3c56543 --- /dev/null +++ b/Documentation/core-api/memory-allocation.rst @@ -0,0 +1,124 @@ +======================= +Memory Allocation Guide +======================= + +Linux provides a variety of APIs for memory allocation. You can +allocate small chunks using `kmalloc` or `kmem_cache_alloc` families, +large virtually contiguous areas using `vmalloc` and its derivatives, +or you can directly request pages from the page allocator with +`alloc_pages`. It is also possible to use more specialized allocators, +for instance `cma_alloc` or `zs_malloc`. + +Most of the memory allocation APIs use GFP flags to express how that +memory should be allocated. The GFP acronym stands for "get free +pages", the underlying memory allocation function. + +Diversity of the allocation APIs combined with the numerous GFP flags +makes the question "How should I allocate memory?" not that easy to +answer, although very likely you should use + +:: + + kzalloc(, GFP_KERNEL); + +Of course there are cases when other allocation APIs and different GFP +flags must be used. + +Get Free Page flags +=================== + +The GFP flags control the allocators behavior. They tell what memory +zones can be used, how hard the allocator should try to find free +memory, whether the memory can be accessed by the userspace etc. The +:ref:`Documentation/core-api/mm-api.rst ` provides +reference documentation for the GFP flags and their combinations and +here we briefly outline their recommended usage: + + * Most of the time ``GFP_KERNEL`` is what you need. Memory for the + kernel data structures, DMAable memory, inode cache, all these and + many other allocations types can use ``GFP_KERNEL``. Note, that + using ``GFP_KERNEL`` implies ``GFP_RECLAIM``, which means that + direct reclaim may be triggered under memory pressure; the calling + context must be allowed to sleep. + * If the allocation is performed from an atomic context, e.g interrupt + handler, use ``GFP_NOWAIT``. This flag prevents direct reclaim and + IO or filesystem operations. Consequently, under memory pressure + ``GFP_NOWAIT`` allocation is likely to fail. Allocations which + have a reasonable fallback should be using ``GFP_NOWARN``. + * If you think that accessing memory reserves is justified and the kernel + will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``. + * Untrusted allocations triggered from userspace should be a subject + of kmem accounting and must have ``__GFP_ACCOUNT`` bit set. There + is the handy ``GFP_KERNEL_ACCOUNT`` shortcut for ``GFP_KERNEL`` + allocations that should be accounted. + * Userspace allocations should use either of the ``GFP_USER``, + ``GFP_HIGHUSER`` or ``GFP_HIGHUSER_MOVABLE`` flags. The longer + the flag name the less restrictive it is. + + ``GFP_HIGHUSER_MOVABLE`` does not require that allocated memory + will be directly accessible by the kernel or the hardware and + implies that the data is movable. + + ``GFP_HIGHUSER`` means that the allocated memory is not movable, + but it is not required to be directly accessible by the kernel or + the hardware. An example may be a hardware allocation that maps + data directly into userspace but has no addressing limitations. + + ``GFP_USER`` means that the allocated memory is not movable and it + must be directly accessible by the kernel or the hardware. It is + typically used by hardware for buffers that are mapped to + userspace (e.g. graphics) that hardware still must DMA to. + +You may notice that quite a few allocations in the existing code +specify ``GFP_NOIO`` or ``GFP_NOFS``. Historically, they were used to +prevent recursion deadlocks caused by direct memory reclaim calling +back into the FS or IO paths and blocking on already held +resources. Since 4.12 the preferred way to address this issue is to +use new scope APIs described in +:ref:`Documentation/core-api/gfp_mask-from-fs-io.rst `. + +Other legacy GFP flags are ``GFP_DMA`` and ``GFP_DMA32``. They are +used to ensure that the allocated memory is accessible by hardware +with limited addressing capabilities. So unless you are writing a +driver for a device with such restrictions, avoid using these flags. +And even with hardware with restrictions it is preferable to use +`dma_alloc*` APIs. + +Selecting memory allocator +========================== + +The most straightforward way to allocate memory is to use a function +from the :c:func:`kmalloc` family. And, to be on the safe size it's +best to use routines that set memory to zero, like +:c:func:`kzalloc`. If you need to allocate memory for an array, there +are :c:func:`kmalloc_array` and :c:func:`kcalloc` helpers. + +The maximal size of a chunk that can be allocated with `kmalloc` is +limited. The actual limit depends on the hardware and the kernel +configuration, but it is a good practice to use `kmalloc` for objects +smaller than page size. + +For large allocations you can use :c:func:`vmalloc` and +:c:func:`vzalloc`, or directly request pages from the page +allocator. The memory allocated by `vmalloc` and related functions is +not physically contiguous. + +If you are not sure whether the allocation size is too large for +`kmalloc`, it is possible to use :c:func:`kvmalloc` and its +derivatives. It will try to allocate memory with `kmalloc` and if the +allocation fails it will be retried with `vmalloc`. There are +restrictions on which GFP flags can be used with `kvmalloc`; please +see :c:func:`kvmalloc_node` reference documentation. Note that +`kvmalloc` may return memory that is not physically contiguous. + +If you need to allocate many identical objects you can use the slab +cache allocator. The cache should be set up with +:c:func:`kmem_cache_create` before it can be used. Afterwards +:c:func:`kmem_cache_alloc` and its convenience wrappers can allocate +memory from that cache. + +When the allocated memory is no longer needed it must be freed. You +can use :c:func:`kvfree` for the memory allocated with `kmalloc`, +`vmalloc` and `kvmalloc`. The slab caches should be freed with +:c:func:`kmem_cache_free`. And don't forget to destroy the cache with +:c:func:`kmem_cache_destroy`.