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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A790C433B4 for ; Fri, 14 May 2021 14:51:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C901661482 for ; Fri, 14 May 2021 14:51:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232509AbhENOwX (ORCPT ); Fri, 14 May 2021 10:52:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232925AbhENOwX (ORCPT ); Fri, 14 May 2021 10:52:23 -0400 Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0C10C061574 for ; Fri, 14 May 2021 07:51:11 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id z1so46614ils.0 for ; Fri, 14 May 2021 07:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MKWQidtDHyEuZAp1OodZw8MInhWEOpr8dYrQ8eCUkc8=; b=XcpiXMVqZIazgKGdvYXDq5jd5KRWzU48G9WzAlP1otwRcy0P5gkJ3wlWzKn8bY2zZs Xksa6W7UbPWaUlPvPOM8taRBFVQ3btAoX/miGWy6RTvEtnsywPkP+zzSNT9vuybcKSzC 2eBjLdu9hcDQKDM/NUJOMqX0jxgoyaq7gniWwSslZTuGfqK+pBuMewNrmgJ6guGvtTl6 JouAQ6RmiUVo/JNtMtDJiqZ2JsP+ddWOtOobC6Q+1s3FhVJ3nlcahcAMIMoCWf8j1+qY vbPEg83w0T5WhznFDAerm+JdAWbsWy8FJq1g30svpBB2eatBhsIMgKtjk8XC/weNKwAO hEpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MKWQidtDHyEuZAp1OodZw8MInhWEOpr8dYrQ8eCUkc8=; b=WUslDfLMUehouKfas896SSiPNn4ojmoUcMkB+yc7bBX1ZG4VlBqEusWGWJguk5J2rs VGZZnZcq8/PQT9F94q5dxStSEblOgkal9+N4vT8ZemhT4PakDWLoPphyQgkcf9QJl3IF K5RVDKlr1jLAW+hDW463U3g1HnTbY5BKqRlu1N/3VbpEKlnk8O9WRj1vbDnDWW7Zne3L dIs/ZbBgNhtuhVZfTAkow2EA4nZnM5+LOuhwQhuKGWibCz8Q9rr/2kSiBEBzfhP4xGXw I4UV2NMxRNNXTVnLylgL4G96UA4M3WI/+jwAawFIP0SBF+A6IW2b0+ch8Ij3gu5Uv2ZA uusQ== X-Gm-Message-State: AOAM532RMkVd/yj7ZGQGWVa5rWgGKbvvU6nAue96pVvmRupPt/UVzoTz 5EwlezzpxbVejPTLg0JzaS3CNeTLBZ7reQ== X-Google-Smtp-Source: ABdhPJy9zLvG8smxgUa+PYTqFIMaw3tTy6ZDupY8mkefJehzJRwuKS7iRauAsWG4cASOxKpunq+OXw== X-Received: by 2002:a05:6e02:671:: with SMTP id l17mr40799517ilt.267.1621003870918; Fri, 14 May 2021 07:51:10 -0700 (PDT) Received: from [192.168.1.30] ([65.144.74.34]) by smtp.gmail.com with ESMTPSA id d2sm3230057ile.18.2021.05.14.07.51.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 May 2021 07:51:10 -0700 (PDT) Subject: Re: [PATCH] io_uring: increase max number of reg buffers From: Jens Axboe To: Pavel Begunkov , io-uring@vger.kernel.org References: Message-ID: <62421d38-a843-f769-aae4-6a8f5c43aa5f@kernel.dk> Date: Fri, 14 May 2021 08:51:10 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On 5/14/21 8:42 AM, Jens Axboe wrote: > On 5/14/21 5:06 AM, Pavel Begunkov wrote: >> Since recent changes instead of storing a large array of struct >> io_mapped_ubuf, we store pointers to them, that is 4 times slimmer and >> we should not to so worry about restricting max number of registererd >> buffer slots, increase the limit 4 times. > > Is this going to fall within the max kmalloc size? Ah yes, it's just a u64 now, so should be fine. Might be worth considering using vmalloc() for this in any case in the future, to make the allocation more reliable. 128K of contig memory can sometimes be an issue in prod. -- Jens Axboe