From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC54BC6FD18 for ; Wed, 19 Apr 2023 08:39:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E3008E0002; Wed, 19 Apr 2023 04:39:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 592D48E0001; Wed, 19 Apr 2023 04:39:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4597D8E0002; Wed, 19 Apr 2023 04:39:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 32F488E0001 for ; Wed, 19 Apr 2023 04:39:47 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F03D61201D9 for ; Wed, 19 Apr 2023 08:39:46 +0000 (UTC) X-FDA: 80697492372.22.6F378AE Received: from us-smtp-delivery-110.mimecast.com (us-smtp-delivery-110.mimecast.com [170.10.129.110]) by imf26.hostedemail.com (Postfix) with ESMTP id E2447140011 for ; Wed, 19 Apr 2023 08:39:44 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=globallogic.com header.s=mimecast20210517 header.b="K4Z/PQF6"; spf=pass (imf26.hostedemail.com: domain of sergii.piatakov@globallogic.com designates 170.10.129.110 as permitted sender) smtp.mailfrom=sergii.piatakov@globallogic.com; dmarc=pass (policy=reject) header.from=globallogic.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681893585; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=pmty6Z3i6AqK9upEu19BmaxMq1ZvTXOUGffgKfE2WKU=; b=k4xf9lBAo6HnpRCrMf5Rvx1h1gXhCandcReUFu1qrrCCVYq+OBC5svf17/f1ruTtdEJdfu XkgfI/Zfa3nPGZDdW1sGq+2muK+5JGB64B6/Ac5qwasP+zJy1kGeUocdbn/jeSrmg73k9T fL/H5tHDAhVQo/6rn5jV3IogK8eOSLg= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=globallogic.com header.s=mimecast20210517 header.b="K4Z/PQF6"; spf=pass (imf26.hostedemail.com: domain of sergii.piatakov@globallogic.com designates 170.10.129.110 as permitted sender) smtp.mailfrom=sergii.piatakov@globallogic.com; dmarc=pass (policy=reject) header.from=globallogic.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681893585; a=rsa-sha256; cv=none; b=yD+u/c1ucuO7/0l9znoYE7QMz7Ts2m+/8FaEPcXujTqi+cPfxfhNcpUEpTTL4XdS1mnBzO K2wfMn3tiG5YpAIF62oIlEAKW0Eoo9aMFbgYoN/D/FWgm96llQVfWy06ufEyvFYkOVYMlP wfypkG49UViUtD6gFdJqXcjh73hrMRw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globallogic.com; s=mimecast20210517; t=1681893584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=pmty6Z3i6AqK9upEu19BmaxMq1ZvTXOUGffgKfE2WKU=; b=K4Z/PQF6qUX+LzcPZXzkIQUE1P7Xh5VZrNbAvMnrGci7tpeAZ0rMu7KxAUsNmB7pY0jLoU rkINHPpuPTAAc/3UzGiB65Adv29IGXj1keaXoMEwhdZvphFXYZ3Pqc7lbq09XTd6/oGlgg 4B1D5L2n6yt8HBY8Zj/TahmkrW+GiG+VN5d7mdSOOk4tQrrjgcxb4KWICzQFZHEAc4o84v PyhTX1eTX6U85upzXfTiA1zeHMzcTWXNqy/VkSLOaXSy8oJZWET52tBG52CMfGUhnHuhXe km9Ilcinjd0d9PhWNZZgowGU+kWedEz8pY9R6Ww7/iNjiFbWfokgfIjPmHnegw== Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-615-EGorZJUyOS6LNxhaVW9URQ-1; Wed, 19 Apr 2023 04:39:43 -0400 X-MC-Unique: EGorZJUyOS6LNxhaVW9URQ-1 Received: by mail-ed1-f72.google.com with SMTP id g1-20020a50d5c1000000b00506955403b5so5997965edj.23 for ; Wed, 19 Apr 2023 01:39:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681893582; x=1684485582; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VBZ4v02+DP4JtA3av4tOJ+0lImTBUH0VfKBzwC3dXEg=; b=H7Fo2nmvh2EcuKDqpl1IvSqsbkCLIJALnYXhnH3G3CukithaevJ6eXJgRu3BPP3+TI 48XRlulstziGy8eX/KdjTXtFLAsHMlvQG37Noyiw0SaaDXEIq7c5s5bEX2QiiyyqEiRm sPQuyMHD7YsrTN8SAD3uH9ZAQGQ/6/uHFKFVpsB1jEFBmNr3vYVL0aopCAffkzLy8fUb dB85BpI5eBIJeJqQPc3x7Lv6F3gqaILL4Qr0hvV3ZP9N+hZ2zUcHblUGtSL7CPOT3l5A EodSyULZ6M0e5aml5M6RJXFVMjWGt1/4ortkrrWso4XJ7lGKvYcBkSYBI5ldgoGtLx3h meAw== X-Gm-Message-State: AAQBX9egPRD51Rcgj5bVJ8G8DB75k9mV/03DHDB7W4+i7QksMjFxKxok Ol6kw6ZA9x4Yq6Oow11p8HTR77TblDyup0eSBL/6zoGnIu8oVThXhcoGYLZmBxLbFPgDFPtkefr 3ZJtOxJVXUA== X-Received: by 2002:a17:906:a945:b0:932:4255:5902 with SMTP id hh5-20020a170906a94500b0093242555902mr13761208ejb.76.1681893581963; Wed, 19 Apr 2023 01:39:41 -0700 (PDT) X-Google-Smtp-Source: AKy350aWKN12QTZg4c6/Skev4owyJrNvF9hpR+QceWVxjbOF/fFurjp7eUCHIdsLAXLyvcj6wPUIMg== X-Received: by 2002:a17:906:a945:b0:932:4255:5902 with SMTP id hh5-20020a170906a94500b0093242555902mr13761177ejb.76.1681893581545; Wed, 19 Apr 2023 01:39:41 -0700 (PDT) Received: from kbp1-ldl-a16430.synapse.com ([193.19.255.131]) by smtp.gmail.com with ESMTPSA id d9-20020a170906640900b0094f58a85bc5sm4698590ejm.180.2023.04.19.01.39.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Apr 2023 01:39:41 -0700 (PDT) From: Sergii Piatakov To: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Steffen Zachaeus , Gotthard Voellmeke , Yaroslav Parkhomenko , Sergii Piatakov Subject: [PATCH mm/cma] mm/cma: retry allocation of dedicated area on EBUSY Date: Wed, 19 Apr 2023 11:38:51 +0300 Message-Id: <20230419083851.2555096-1-sergii.piatakov@globallogic.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: globallogic.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E2447140011 X-Stat-Signature: 1mrzphasd3o4fx7wr1awgpj6copa3t9r X-HE-Tag: 1681893584-597083 X-HE-Meta: U2FsdGVkX19Bw0lCQbWME2A4WuEEgezVFMomJfMhvL1JNN7XlLzhPysYfXjQDnigSJYvku9KdymMoOnvYMkEpD96IgctxQ2dRBkwin9t3gSERZ+cKSk723sR5+gkY/VnfYABwMXcAK4n2B09DIaC1EbsCPNicpEVNBx2c5DlPjBKu+qySHTe5d7bGM3Xlo4sekOMNHr775HJ+mn8zmV/zT9BjwvGpMY7hy8bXvifqIWGKFAZgjLR7EYfxGC68JMe0TzPcEFLIsse1mc2cO8vaaUHnN4KBmgnAUpbJD24prz4TlNHYr0NSrF+kOc+NCRLtoZ+K78xvDjDCwty39pd2Mx6ag4yjFXPMXhPa0ZK+CLRb51NTp4fCcT2/FsQwNgxAjxu15MgDsdWyUlHytUVYrFPjFXptH9cV4NW3k7h/1SA0lZ8R8qse6zi+OH8joMssgZtzTGavH640R4yTyZcDNfzd/ziVEBwcj5M/FjWZM+H/GjkuGG70tBJtKjfIW3rkHUCsRR+9e5/u9824kl0hYePPkWoWITLE6kkSF7VACXtLS4HAJIPIWHCzfd52rey+bLAa9XMaqQAJZwKCBU1wxFXN8eqJbjrRnwDbVhIInvwiIHBzw/FYjS5LXTLMhRVDA1t1Eykzb3aV4elehqxvOu4yTKEM2qOGTOyrrwf6PlCp9aDr6qd7XzJWj1+MfniitgwwMFnFeunGX0RInEsfFKPVyI/myRylpTP2zFO1PYW6nvaGdJLY7RMdo2oLzsCKtbhEjBQdbAwRmGw6N11/BJdnpLtN/QLuWqUo1YEfnktM8g8nMIU06frPpz272/5vUVOX6OGwkBjtZLScaFvD3Pnykjv9SK55Uu81gvdGW+MU1Bs2QkqXHKK0lU2XZQVEXin9L0AipqpI1MiwAPQAxSwvc34JFqb36Tl9i5kHbU/xxJodppqW7iLDCcz2cqE40AgUqb7Aqsp+WkDfyB poSd7W1i F612TB0LZdT/2OQfYbBJUZsenT2abGQQir9kr3CqEW/oxkCzFP58T7boHYNwfF0LgHRFMbKVGVYcbIlSfyZUOUDP/hTObnPXbcY+Yaj3ULIrJM75CNVf4FwJTliR3BK1gYjH8J0iGFcKiTN4TRT1KtjuVqo7pf9UbmKOMJPxrqVo6frRBssvIFu1BlnswkEwDFZeEB5vZIlguLTSbCKuUMtnAedH2cBgoJdaipgAZBlsYSOtrEyBjo3aQARjaJqAA38XbveJ1Xn4uQf3wuE3S4/63BZdQGMovQ1cOPFN9oPfN6LzYZe+FbNR1KLvJWMW5+2NW4JOdXpaP59bcSnkQAy71pskrICwJun0DBC0oUIkDNPREVC48lgS7zKUWrkUKrqOnST3jtYWlVhgtkwTAZbLbzdYOTKNnc9+tFYTHd827Xm1afqAUn1rYHgnsOIr8P2dGohSPNGL8v5M= 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: Sometimes continuous page range can't be successfully allocated, because some pages in the range may not pass the isolation test. In this case, the CMA allocator gets an EBUSY error and retries allocation again (in the slightly shifted range). During this procedure, a user may see messages like: alloc_contig_range: [70000, 80000) PFNs busy But in most cases, everything will be OK, because isolation test failure is a recoverable issue and the CMA allocator takes care of it (retrying allocation again and again). This approach works well while a small piece of memory is allocated from a big CMA region. But there are cases when the caller needs to allocate the entire CMA region at once. For example, when a module requires a lot of CMA memory and a region with the requested size is binded to the module in the DTS file. When the module tries to allocate the entire its own region at once and the isolation test fails, the situation will be different than usual due to the following: - it is not possible to allocate pages in another range from the CMA region (because the module requires the whole range from the beginning to the end); - the module (from the client's point of view) doesn't expect its request will be rejected (because it has its own dedicated CMA region declared in the DTS). This issue should be handled on the CMA allocator layer as this is the lowest layer when the reason for failure can be distinguished. Because the allocator doesn't return an error code, but instead it just returns a pointer (to a page structure). And when the caller gets a NULL it can't realize what kind of problem happens inside (EBUSY, ENOMEM, or something else). To avoid cases when CMA region has enough room to allocate the requested pages, but returns NULL due to failed isolation test it is proposed: - add a separate branch to handle cases when the entire region is requested; - as an initial solution, retry allocation several times (in the setup where the issue was observed this solution helps). Signed-off-by: Sergii Piatakov --- mm/cma.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/mm/cma.c b/mm/cma.c index a7263aa02c92..37e2bc34391b 100644 --- a/mm/cma.c +++ b/mm/cma.c @@ -431,6 +431,7 @@ struct page *cma_alloc(struct cma *cma, unsigned long c= ount, =09unsigned long i; =09struct page *page =3D NULL; =09int ret =3D -ENOMEM; +=09int retry =3D 0; =20 =09if (!cma || !cma->count || !cma->bitmap) =09=09goto out; @@ -487,8 +488,26 @@ struct page *cma_alloc(struct cma *cma, unsigned long = count, =20 =09=09trace_cma_alloc_busy_retry(cma->name, pfn, pfn_to_page(pfn), =09=09=09=09=09 count, align); -=09=09/* try again with a bit different memory target */ -=09=09start =3D bitmap_no + mask + 1; + +=09=09/* +=09=09 * The region has enough free space, but it can't be provided right = now +=09=09 * because the underlying layer is busy and can't perform allocation= . +=09=09 * Here we have different options depending on each particular case. +=09=09 */ + +=09=09if (!start && !offset && bitmap_maxno =3D=3D bitmap_count) { +=09=09=09/* +=09=09=09 * If the whole region is requested it means that: +=09=09=09 * - there is no room to retry the allocation in another range; +=09=09=09 * - most likely somebody tries to allocate a dedicated CMA regi= on. +=09=09=09 * So in this case we can just retry allocation several times wit= h the +=09=09=09 * same parameters. +=09=09=09 */ +=09=09=09if (retry++ >=3D 5/*maxretry*/) +=09=09=09=09break; +=09=09} else +=09=09=09/* In other cases try again with a bit different memory target */ +=09=09=09start =3D bitmap_no + mask + 1; =09} =20 =09trace_cma_alloc_finish(cma->name, pfn, page, count, align, ret); --=20 2.25.1