From patchwork Thu Aug 16 13:03:38 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 10567421 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 25B1313B6 for ; Thu, 16 Aug 2018 13:04:06 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0EFBB29F39 for ; Thu, 16 Aug 2018 13:04:06 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 030B82B027; Thu, 16 Aug 2018 13:04:05 +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 C9E2629F39 for ; Thu, 16 Aug 2018 13:04:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 07E5B6B0266; Thu, 16 Aug 2018 09:04:03 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 011A36B0269; Thu, 16 Aug 2018 09:04:02 -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 E0FD86B0269; Thu, 16 Aug 2018 09:04:02 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id 79F866B0010 for ; Thu, 16 Aug 2018 09:04:02 -0400 (EDT) Received: by mail-wm0-f72.google.com with SMTP id f11-v6so2622578wmc.3 for ; Thu, 16 Aug 2018 06:04:02 -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=uIqXUnIXwdsPxpFxlNOWqudnbM3u/r1sn9iBD+wPcic=; b=Tnn+uC9xnRneTdZZ8oI5/yj216+f680cgaPMJMJOGwx1KUKypgikW9CX/rh9sfztmG /a0+5CEa6DjT4XIPp/vV7XyIslWMvBL5eGSQeamMxq+EpP0AIVReFT+kZab/O1+RXpmO o5F8cgU16N+UrGAvSBMFszJf5sGoQRj0b7MN1SmDyF3u0wFk3m2SgY9Bs5PMw5qV90bo 87qAHSfBGBAOhVMrFz0GDZp83892FfnK9AXLkxxQ5dyRnMoZGCKQtfYnLc8wPuiFa0aq 85r0CCVJiKYXhIqsa2sldKP4e85CRG25AgvV/aYtGqfcM6B/6lvaUJMBZOvYTRG+7cGN Sf5w== X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 148.163.158.5 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: AOUpUlHTz+Mxa2/o8vkZJLdBuavYA6nZo5VVZoTjG9kZwF2fmLUhaUzH qm6LU3YeIqMnspHJNgTboCrcJ20bxgGJK99Q9npsevix6QMOblALs0DfmNC0DpFs4w2+uu/tB6c jw+lgl4gbFnI3UFtQFEkTpmGHZLYKbQYg8Tb0vrph4pQbuKNVogcGdipa89yJNZg= X-Received: by 2002:a1c:6546:: with SMTP id z67-v6mr14771904wmb.130.1534424641938; Thu, 16 Aug 2018 06:04:01 -0700 (PDT) X-Google-Smtp-Source: AA+uWPxA68x4WJpk1VXalIR+KDPLjo5YVvgVOzmXEl941G0lGyH30nxeVuy27NJLS+7yLSEMfKd9 X-Received: by 2002:a1c:6546:: with SMTP id z67-v6mr14771833wmb.130.1534424640388; Thu, 16 Aug 2018 06:04:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534424640; cv=none; d=google.com; s=arc-20160816; b=SC3JVlu7lpOmMQS7Z2OssrbqeVYh9Vp+PNtGdnXbxwpofeducVyoPpq0+ovEpqdBha FT6TAWseOK1bA2fA/zfA7T9a/vZrmP6G35HVpiT/D9F905xOGhNSR8f6v96Dcr3TBt0R ejzmYGSMENi5aHSYOJljTwX4t2eSEpPn1/aVzvvYUVBr/MXbldrmRISgp+yNuYInqLT5 0vG44Ku7A9XOvV5AxBiGcbaHZOSmN38EUTPK6bsegxAvn+cbkZ0hc18xfFL283usWMlR FFmhyfS9rDh/wCVTh+VEVgfG/rZNdBP7NkKj0AvmXLVNm5P55IFX/eH8v6yRsrr/zfv/ 55TA== 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=uIqXUnIXwdsPxpFxlNOWqudnbM3u/r1sn9iBD+wPcic=; b=db74CusIzePVgTLfzDVjqKzoHc2muOOMQ3d6OwnlLicnSwRF8eQlMoIKenqTLFFCur x+INLY3194ZS0Ril4u2ibLMDNNCeVYrZ3zK/L794Y4/tcsAhPX6yFn734E8b9Gja9CVT u706VwVbOg7JNfKqQx3MSnVzmoDP5qOifmNGjzi6dADTz+ij28ISQH1koVdB6O+nKWVV LRzqi+xwHTLudL+/dge0VHXqj6UOy672OD8qqI8J3bV8Dv7/1jelOto7RghujsNvUi1L wjP1zJKATiNGI1Q+vfAWNe6ar8EWFz7ROPfVl4ahl8bOEU6+5Im3gyYSdyDaYGB93FxZ PodA== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 148.163.158.5 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 (mx0b-001b2d01.pphosted.com. [148.163.158.5]) by mx.google.com with ESMTPS id t8-v6si761529wmc.124.2018.08.16.06.03.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Aug 2018 06:04:00 -0700 (PDT) Received-SPF: neutral (google.com: 148.163.158.5 is neither permitted nor denied by best guess record for domain of rppt@linux.vnet.ibm.com) client-ip=148.163.158.5; Authentication-Results: mx.google.com; spf=neutral (google.com: 148.163.158.5 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 (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7GD00Um064185 for ; Thu, 16 Aug 2018 09:03:58 -0400 Received: from e06smtp01.uk.ibm.com (e06smtp01.uk.ibm.com [195.75.94.97]) by mx0b-001b2d01.pphosted.com with ESMTP id 2kw9ehh0d6-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 16 Aug 2018 09:03:56 -0400 Received: from localhost by e06smtp01.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 16 Aug 2018 14:03:54 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) 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) Thu, 16 Aug 2018 14:03:50 +0100 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w7GD3nYT46137512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Aug 2018 13:03:49 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9E1AD4203F; Thu, 16 Aug 2018 16:03:53 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0551042041; Thu, 16 Aug 2018 16:03:52 +0100 (BST) Received: from rapoport-lnx (unknown [9.148.8.148]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Thu, 16 Aug 2018 16:03:51 +0100 (BST) Received: by rapoport-lnx (sSMTP sendmail emulation); Thu, 16 Aug 2018 16:03:46 +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 v2 3/3] docs: core-api: add memory allocation guide Date: Thu, 16 Aug 2018 16:03:38 +0300 X-Mailer: git-send-email 2.7.4 In-Reply-To: <1534424618-24713-1-git-send-email-rppt@linux.vnet.ibm.com> References: <1534424618-24713-1-git-send-email-rppt@linux.vnet.ibm.com> X-TM-AS-GCONF: 00 x-cbid: 18081613-4275-0000-0000-000002AAB68C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18081613-4276-0000-0000-000037B3DCB7 Message-Id: <1534424618-24713-4-git-send-email-rppt@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-16_03:,, 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-1808160137 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..b9b0823 --- /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 HW 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`.