Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp4784146pxb; Tue, 25 Jan 2022 19:35:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJy1U0d7TnU/TEqWUvgHvR82bn7uwa/F5OdUc/hXZlXThuJ5pL7yb0ONkZEpbDR0pCUipYsY X-Received: by 2002:a65:5bc4:: with SMTP id o4mr17091924pgr.489.1643168110201; Tue, 25 Jan 2022 19:35:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643168110; cv=none; d=google.com; s=arc-20160816; b=fASwiu1dSXxSJh2W2Ejuu3kpchJvUWJ8VQvyCpNcd7Y7dOHQLumr0Aw7Fy9kl4ZO0H k3VOC/dbqA31Uj1ecNmvQRb/mclLt/BrLdCWgYUrfSDu0TX4HwdkKhwztdnx4CtBqHr7 ktS6QLQdMZioNUfMVNayYSMi0oFtamB9seqQeZnkEbgyrl4dx68mhRhqdoQFHu9dbhAB VBlTYLj0oNQaEyxLGKPzwhwt6wG3y2ZgAf7EQMO5zFJfgT2oRb+WyJ8BnRqlKkBZ6CVa VaeWAHtCmXkqHAxMbKpccZMk32IWdfExEC2Rwh5Rb/tiYzVwbPMd0CIL/Qoo/CnqBcPe ZCQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=l7lUxEYolU+vrePYlAdUz/HMspuBnKr+CPn2t+D6Als=; b=ZV5ww7X1HTlojn/OAYg1933IvaP75/3+SSL2HYb6cPujwfpwUaY9PEEdIZORmGLrt6 +QKbpNyMY5yaDhrK+8f4ITbiKbhPBEUeqj2MJoyT9+JmHH0c5/wc1w3U5MNuTdMlNNDX R/KR3UV1Chrg40u8+9AALCaZ8cTRLlZX+7ETZA0i3dgU8XudPijLHCyJEThf/bX6gvGw 6oCTHcrop9n0W7Bowa17VjC8Uqu0x/H3555Ux3UZACf1s/0OI3acSX3E6vDuBBF5Gw/9 FJaraRghodtkrpkKO4Xqp72K5zOE6GvNMTnv+nRiW88qjOp2WiwzuJu/HzIFp/YTxaPA zdUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=adDbN80v; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l3si1689517pjz.39.2022.01.25.19.34.58; Tue, 25 Jan 2022 19:35:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=adDbN80v; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232714AbiAYSfq (ORCPT + 99 others); Tue, 25 Jan 2022 13:35:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232704AbiAYSfo (ORCPT ); Tue, 25 Jan 2022 13:35:44 -0500 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DF70C06173B for ; Tue, 25 Jan 2022 10:35:44 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id o11so3590676pjf.0 for ; Tue, 25 Jan 2022 10:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=l7lUxEYolU+vrePYlAdUz/HMspuBnKr+CPn2t+D6Als=; b=adDbN80v/yzdqXnlwhZG3lQu7WKIfcd43UuporRcdZ1YPGKtpqXMKQm5lPnUmkHfK9 GDpAht3amkKBrP7qYMMvXj6cTfUu2snK8ZAl5vys28r3PpApO27dZgnd1uhFDZvrZYWd QexX9WrZTVjkgnSNDCK1nC/5idOUOacS0EDbleqhmiADSHze5p6JHos9r+wHATkn8P6o ZtTAXy8dzcZrlEe9ykSCDmN1qm4e3G40XonL5l+3KsIO2VUzekWGAhs3Drs3vOTjAJpL QfIsGCOVrhvkw3YgHu/y9nmmha2rI2D2JW9juIGPKSJueKv1D/P9oMb72qj9iQjpCm+K J+ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=l7lUxEYolU+vrePYlAdUz/HMspuBnKr+CPn2t+D6Als=; b=HnjuGtp0Qr244nXNu6uF5JzdIYJJKsocWPPB/rb6SZ88aI/ZeE1NUiR8WGGof7MzfG m9iYEZmizsnDZPcCPO/yB7m6QHAtrPdCb7GPjrCaAOpXdMgS7WptTDju5jdtC6VTx0BP IVDn1HOeFKBvGXaLD17Vv0LUYLl4NxmWbz3NdVrpnUnfpAIwQpfaw/f/6aRC/2RngcU9 C1Vzpu0tMKdI7BVHB/f1fOLfA9r2BPECw2NzfLQFlzKVaR5Xpqef4eib00EB+j2ZtXk5 /qWE4YSsILWMKzkcaz3IEqRmRajdgjV/FYqGNtxwQCE8/+2jJXZKCAhakv9n4g//9sNl EAEg== X-Gm-Message-State: AOAM530wDv3cXBHNGKutmKDiwQ+3TsfFmLvblAuAD9vDa58ZyEcjIAVP 3OIdl+8Jnq44czH3lvNhI7Zf7w== X-Received: by 2002:a17:902:8695:b0:149:cb5d:ddf1 with SMTP id g21-20020a170902869500b00149cb5dddf1mr20526862plo.103.1643135743371; Tue, 25 Jan 2022 10:35:43 -0800 (PST) Received: from [2620:15c:29:204:6f7a:fc02:d37c:a8b0] ([2620:15c:29:204:6f7a:fc02:d37c:a8b0]) by smtp.gmail.com with ESMTPSA id b9sm20373466pfm.154.2022.01.25.10.35.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jan 2022 10:35:42 -0800 (PST) Date: Tue, 25 Jan 2022 10:35:42 -0800 (PST) From: David Rientjes To: Shakeel Butt cc: Jens Axboe , Pavel Begunkov , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org Subject: Re: [PATCH] mm: io_uring: allow oom-killer from io_uring_setup In-Reply-To: <20220125051736.2981459-1-shakeelb@google.com> Message-ID: <2bec4db-1533-2d39-77f9-bf613fc262d9@google.com> References: <20220125051736.2981459-1-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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().) > Signed-off-by: Shakeel Butt > --- > fs/io_uring.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/fs/io_uring.c b/fs/io_uring.c > index e54c4127422e..d9eeb202363c 100644 > --- a/fs/io_uring.c > +++ b/fs/io_uring.c > @@ -8928,10 +8928,9 @@ static void io_mem_free(void *ptr) > > static void *io_mem_alloc(size_t size) > { > - gfp_t gfp_flags = GFP_KERNEL | __GFP_ZERO | __GFP_NOWARN | __GFP_COMP | > - __GFP_NORETRY | __GFP_ACCOUNT; > + gfp_t gfp = GFP_KERNEL_ACCOUNT | __GFP_ZERO | __GFP_NOWARN | __GFP_COMP; > > - return (void *) __get_free_pages(gfp_flags, get_order(size)); > + return (void *) __get_free_pages(gfp, get_order(size)); > } > > static unsigned long rings_size(unsigned sq_entries, unsigned cq_entries, > -- > 2.35.0.rc0.227.g00780c9af4-goog > > >