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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 61355C433E0 for ; Wed, 13 May 2020 17:42:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CD692205ED for ; Wed, 13 May 2020 17:42:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="CuNHH4dt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CD692205ED Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D131680028; Wed, 13 May 2020 13:42:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9CA88000B; Wed, 13 May 2020 13:42:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8AA980028; Wed, 13 May 2020 13:42:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9D3DC8000B for ; Wed, 13 May 2020 13:42:35 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5582A1F08 for ; Wed, 13 May 2020 17:42:35 +0000 (UTC) X-FDA: 76812415470.05.worm97_6ddfb4827e656 X-HE-Tag: worm97_6ddfb4827e656 X-Filterd-Recvd-Size: 5683 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 May 2020 17:42:34 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id u6so520616ljl.6 for ; Wed, 13 May 2020 10:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pQS9PZSZkC7J4FQkV4xe75LJQYCCMj17Z0oYFTEHPAg=; b=CuNHH4dtXsRN1EAJPY6PDuqYboQGoRqGyFQeIKled0eFTwTjnqRO8hPh+XtFI8pLKe PvVnJ1iMi2tr/lQ0jytjS5UFXtomk896SeiJJyJ84jTl+75H9tAOAeaBylYcdzNdhEvt FjJKbe8B4hccHFVGQ3h5oEYjUI1bJeIuzrgC0NkX7qyEXxl/MgoB9t0uq2618qIgXxZx dRk04iTv7iKcfzfo7TqtNb17hsuwh/KQYPnE1FCebmt/nIy8iIPXzZCukM+2zNFEsnbe R42fMBIfkcOlF4iSwKE7leE2cr70zuMXFzgk1v8BmZwVxzGo2Zw6WDiDGMtrxFnIiiLY +L9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pQS9PZSZkC7J4FQkV4xe75LJQYCCMj17Z0oYFTEHPAg=; b=H0MGgA6wfPmZsrgODx1t+PqfKhaIi6l5JQDQsj+r2m2MF6jQ/wZSVcgzk1zsOzJymt eE8Wh1xtLDxt4+sljU6ByPPwtRujEDK5ErVihKgSmpMaNxLb4GQ9isrN5iVBtSMPZt+u GG/e8XFOLQYZrYSAcJH43lbw0MxhXq/d1u4YZ7S2K6bmjY8wiM0nM3VffEvv68QYbP6G sWhWCk0yQSFXeIU/umG0DxK9ThaqCvKZIjOjvrREvMoxz0PcrU4oaYtUsHSOu4xWGtH+ 8ZcGko1uIoEmFlZt5/NgwGFK6ap/Haqxo2gDqEvO+zWS1svj5QktAcqr56Qk5rPbG7FT khWQ== X-Gm-Message-State: AOAM5303TIkbSBp6Cie2EcVi46JCgTqwPS5kRMx8bbR405Y9vYBCnyrc 25o+RiJ5oHdUgKVEaUx1dIIMpWR91fveQPqWd5t0zQ== X-Google-Smtp-Source: ABdhPJxpFDG22Y809iXjpQMHfUixwp4Zg6FEPmzfikjpGdIc/OC7MzvC4yQr1nPLFLkafaeIxQrxrSP8aIMPO7qNl2g= X-Received: by 2002:a2e:87d3:: with SMTP id v19mr145416ljj.176.1589391753304; Wed, 13 May 2020 10:42:33 -0700 (PDT) MIME-Version: 1.0 References: <492bb956-a670-8730-a35f-1d878c27175f@kernel.dk> In-Reply-To: <492bb956-a670-8730-a35f-1d878c27175f@kernel.dk> From: Jann Horn Date: Wed, 13 May 2020 19:42:07 +0200 Message-ID: Subject: Re: [PATCH RFC} io_uring: io_kiocb alloc cache To: Jens Axboe Cc: io-uring , Xiaoguang Wang , joseph qi , Jiufei Xue , Pavel Begunkov , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux-MM Content-Type: text/plain; charset="UTF-8" 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: +slab allocator people On Wed, May 13, 2020 at 6:30 PM Jens Axboe wrote: > I turned the quick'n dirty from the other day into something a bit > more done. Would be great if someone else could run some performance > testing with this, I get about a 10% boost on the pure NOP benchmark > with this. But that's just on my laptop in qemu, so some real iron > testing would be awesome. 10% boost compared to which allocator? Are you using CONFIG_SLUB? > The idea here is to have a percpu alloc cache. There's two sets of > state: > > 1) Requests that have IRQ completion. preempt disable is not enough > there, we need to disable local irqs. This is a lot slower in > certain setups, so we keep this separate. > > 2) No IRQ completion, we can get by with just disabling preempt. The SLUB allocator has percpu caching, too, and as long as you don't enable any SLUB debugging or ASAN or such, and you're not hitting any slowpath processing, it doesn't even have to disable interrupts, it gets away with cmpxchg_double. Have you profiled what the actual problem is when using SLUB? Have you tested with CONFIG_SLAB_FREELIST_HARDENED turned off, CONFIG_SLUB_DEBUG turned off, CONFIG_TRACING turned off, CONFIG_FAILSLAB turned off, and so on? As far as I know, if you disable all hardening and debugging infrastructure, SLUB's kmem_cache_alloc()/kmem_cache_free() on the fastpaths should be really straightforward. And if you don't turn those off, the comparison is kinda unfair, because your custom freelist won't respect those flags. When you build custom allocators like this, it interferes with infrastructure meant to catch memory safety issues and such (both pure debugging code and safety checks meant for production use) - for example, ASAN and memory tagging will no longer be able to detect use-after-free issues in objects managed by your custom allocator cache. So please, don't implement custom one-off allocators in random subsystems. And if you do see a way to actually improve the performance of memory allocation, add that to the generic SLUB infrastructure. > Outside of that, any freed requests goes to the ce->alloc_list. > Attempting to alloc a request will check there first. When freeing > a request, if we're over some threshold, move requests to the > ce->free_list. This list can be browsed by the shrinker to free > up memory. If a CPU goes offline, all requests are reaped. > > That's about it. If we go further with this, it'll be split into > a few separate patches. For now, just throwing this out there > for testing. The patch is against my for-5.8/io_uring branch. That branch doesn't seem to exist on ...