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 28B16C47085 for ; Tue, 25 Jan 2022 22:58:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D9806B0075; Tue, 25 Jan 2022 17:58:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 761346B007B; Tue, 25 Jan 2022 17:58:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DA8F6B007D; Tue, 25 Jan 2022 17:58:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0122.hostedemail.com [216.40.44.122]) by kanga.kvack.org (Postfix) with ESMTP id 473246B0075 for ; Tue, 25 Jan 2022 17:58:06 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0262918403BF7 for ; Tue, 25 Jan 2022 22:58:06 +0000 (UTC) X-FDA: 79070324172.14.2E72358 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by imf26.hostedemail.com (Postfix) with ESMTP id A7093140003 for ; Tue, 25 Jan 2022 22:58:05 +0000 (UTC) Received: by mail-lf1-f50.google.com with SMTP id u6so27907786lfm.10 for ; Tue, 25 Jan 2022 14:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vUEaRvAeqO4wB5ShFfH+VshVtU3ztYzAw/eGT2KcLXg=; b=emXX7F+vgI8KhnQH9o8EoWDuLk34WEtKEuctbuMWmeiFTDs04Yti6LC1oiu8hvoE0F 6zHK6uDducjGcgdYBRTb/60kK0eZSzL099gOzXGM+UvZ2vcGKri/cniF0gpJYUVnWRea 6dGK8DLP2OcCP90vFMP7G/3sSDZi7vsl0YXErQRmv4pNYTWuvtBLkg0s3XkX0t93bXLX 1OF5dZjc6ezxkmX4OZJavqEQKMXuh+0Jok/FvIWwPv+o/Ck56Z/kEONKFEdFsr8xnxJ3 6kjKUATDq6/IYyps70N9u/r+ZwJx3zo8OXiUl5ue0/cHQkVTBeKKA9HgNz4/nTD/6vmB uMuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vUEaRvAeqO4wB5ShFfH+VshVtU3ztYzAw/eGT2KcLXg=; b=pMuS5HH5vvuEa1CMYmcZ3bomnhHtjTis7wAZVzYmEs7eZ0GmJtqHyYwP6PRsVA7xsZ DGVuRLfpzFR5orOY3TXAeQWu5jQAfnFuDbyIL6RAV9Bvo8HIHcOjw3spUuHjeBL4QCDR 1TIH8T9HBvBiR9+wu+ni1qx+BrzmKgscrI5XMjREgiaj7TsrtOzZD78fqZJToMd98sOv kKd+lEGmWWVMbdmOHX1QDW/F6dPhYxUYIWX+Gv12wG6oyEdDFyUyhB65cUavjIbHXjjd ZgY+Et4aGF4YCWFtjvn8jLoprJnIW3t51FzJGr6AdwO3kx1LhpBBu19pkfDE1IZWzaZP RMBw== X-Gm-Message-State: AOAM53357ATuMzhev8Zm786I3QZqpqX1Ixn7XbuVg8Q/o6yeJ3cJ6Esz 8NRAM3sgdVPJJh7Z7K4/ntuOp1rIweW85qbU9SsjIw== X-Google-Smtp-Source: ABdhPJzS7mt6iG3Pp05PQnOZLNNTR53sS7DB6BxYN+I6qmf5VodV069J0P5dkoLqwCzN7ToUVidHyehHCQRs1LfEyXA= X-Received: by 2002:a05:6512:33d5:: with SMTP id d21mr18778383lfg.8.1643151483817; Tue, 25 Jan 2022 14:58:03 -0800 (PST) MIME-Version: 1.0 References: <20220125051736.2981459-1-shakeelb@google.com> <2bec4db-1533-2d39-77f9-bf613fc262d9@google.com> In-Reply-To: <2bec4db-1533-2d39-77f9-bf613fc262d9@google.com> From: Shakeel Butt Date: Tue, 25 Jan 2022 14:57:52 -0800 Message-ID: Subject: Re: [PATCH] mm: io_uring: allow oom-killer from io_uring_setup To: David Rientjes Cc: Jens Axboe , Pavel Begunkov , Andrew Morton , Linux MM , LKML , io-uring@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A7093140003 X-Stat-Signature: h45atahpmpgxhqnfrgcgy68xc1oozcji X-Rspam-User: nil Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=emXX7F+v; spf=pass (imf26.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.50 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1643151485-317364 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jan 25, 2022 at 10:35 AM David Rientjes wrote: > > On Mon, 24 Jan 2022, Shakeel Butt wrote: > > > On an overcommitted system which is running multiple workloads of > > varying priorities, it is preferred to trigger an oom-killer to kill a > > low priority workload than to let the high priority workload receiving > > ENOMEMs. On our memory overcommitted systems, we are seeing a lot of > > ENOMEMs instead of oom-kills because io_uring_setup callchain is using > > __GFP_NORETRY gfp flag which avoids the oom-killer. Let's remove it and > > allow the oom-killer to kill a lower priority job. > > > > What is the size of the allocations that io_mem_alloc() is doing? > > If get_order(size) > PAGE_ALLOC_COSTLY_ORDER, then this will fail even > without the __GFP_NORETRY. To make the guarantee that workloads are not > receiving ENOMEM, it seems like we'd need to guarantee that allocations > going through io_mem_alloc() are sufficiently small. > > (And if we're really serious about it, then even something like a > BUILD_BUG_ON().) > The test case provided to me for which the user was seeing ENOMEMs was io_uring_setup() with 64 entries (nothing else). If I understand rings_size() calculations correctly then the 0 order allocation was requested in io_mem_alloc(). For order > PAGE_ALLOC_COSTLY_ORDER, maybe we can use __GFP_RETRY_MAYFAIL. It will at least do more aggressive reclaim though I think that is a separate discussion. For this issue, we are seeing ENOMEMs even for order 0 allocations.