Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp953472imu; Tue, 11 Dec 2018 10:06:44 -0800 (PST) X-Google-Smtp-Source: AFSGD/UGv5f/Y6Foci0Fm+Tl/smV50WzaTg5Jz8LRJDxiwEGvsaWPK77uYOr33dftBSu4MQvSBNu X-Received: by 2002:a63:1766:: with SMTP id 38mr15013482pgx.299.1544551604296; Tue, 11 Dec 2018 10:06:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544551604; cv=none; d=google.com; s=arc-20160816; b=0otDH+BQ57M2IsiR8fpJOaSIimUitHf7Dod+XEtieYaH9/9cDILL9AnYTAn272M61r WbNttWV9f4kzWnhdvTpKH5xUZrfnUsUcbkG6TuaYDjWHqd/TBCc6UiDOhtjIeN/UHW4N ippGWcyYKEmnZQ6iWz3m9N16ZENtxwGu8xXm+9583YhluTB+aufgApDOvEYeqspzyUlS D9xNsD1dwwfSNFqeFs/7zQN3U0zBSjqHXB5uQxNNTDA5m5QVrHy2Qf2QKzjqUOdt95Z7 wYJ/LAWwGq6xcxdkpq0hgaHFO7QLe1WgDazPIaQX+L2daVux/T2DZwCISSDmyk2doVMh 4WMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=pyKR+gozXkLNrKKhrpt5D+hcCDuAYM42zKYof/e8FeM=; b=J7XyGZvtpaAAXOQMp5IWYztXF3EWkiMR8dG21DU1vlIvUancoXo/2Av86XBituBcL4 fRqwoIffx0a5r8BZjwWM+/JcEPAzr753lAY2Y5hxVrKdrZTHwNzmZPR0+i3fFV2YmVhz c5W8uToNoMcE2BUoYTC2z1cyp7IJsheK8PIGqM29qMtWB+X/EDUPfnoqGoA3b2Ln24lg 1ow55KEv0/LS9lBvGIADuUrqbGBqO8i7OEbtk9IP6K68Xm4yMis7sBY7+puUy2K/mQdw WUg0BBThCQP4LWJlFuj1NfADeifbUMVl5AIlQAV869A2+9UcOLILsUjKDMsFSEwimT3j wfcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b="igLkuJ/o"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31si13481171plz.263.2018.12.11.10.06.29; Tue, 11 Dec 2018 10:06:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b="igLkuJ/o"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727023AbeLKSFQ (ORCPT + 99 others); Tue, 11 Dec 2018 13:05:16 -0500 Received: from mail-it1-f181.google.com ([209.85.166.181]:36269 "EHLO mail-it1-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726676AbeLKSFQ (ORCPT ); Tue, 11 Dec 2018 13:05:16 -0500 Received: by mail-it1-f181.google.com with SMTP id c9so5363597itj.1 for ; Tue, 11 Dec 2018 10:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pyKR+gozXkLNrKKhrpt5D+hcCDuAYM42zKYof/e8FeM=; b=igLkuJ/oJsiSD/VhCTm0XFqq0GyhfC2k3d3pbadPl6TV2mciaJdFoC2rrXSi53hjYo 2CWclP/gtjSoP24fcOjo656QkNbkUYupEJXho7WCucSNpAPzlSDs1YKL6I8XiWUVV/gA td/SFCV+XIw6soiX5ffj8wzOFGYuWhhcEAluObv2CfoWNNfqUfnyMjQqp6b4iwb68nhG 1Pq2lUhtJTuvdDPTSCMbdX2k/v+5MbO/6bayx/IP7+J/CwdYyLyNVrqxyZwCJog8bnhy JleTX0ypLBKafhmb3iKXc2BwpKVRiqluh8H8GEqpgzQm0AYgC61/29HT+JCBusuZX0JE Hsqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pyKR+gozXkLNrKKhrpt5D+hcCDuAYM42zKYof/e8FeM=; b=XSyHfR5P3EaoTH+7axHylfTg9/Ct8hpruP1/UVcdC+RR3864+703fiNYUbln1FlvtU DUFAhaIZhQ9vuD2S23SMFV/ynZCvFC0ih5xayxJ5S2CIOMTia9GO31AG2Fn3l87C4z6d PRLCWR7MyYqBgbUM9MohiG2CPCH53Th95MRRQeE2dRDlwOnDZRlJUTTJGBvw7canSmGV NVdb2ov/8EXcQ5AJ0aEcUr9KMJKIpxE6jZWqZ4/pJYGgtwYW7GDaz86vT7gUpk8fqYmM 5WgL72g2ycqWCoOiTlD5oX1NRCidOeogOpOInZ1GyRCkzXk0fib/rZkpFcQGaPdhze7M 6aaQ== X-Gm-Message-State: AA+aEWaEsR0QgTPDUiWgILkoIUIHvykKJsfrAr60UT28d3LVFJe5BdV3 MsRdqpr3eg3n2LJZdgWyob+0Ow== X-Received: by 2002:a24:5a8f:: with SMTP id v137mr3040345ita.65.1544551514803; Tue, 11 Dec 2018 10:05:14 -0800 (PST) Received: from [192.168.1.56] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id 79sm1620832itx.11.2018.12.11.10.05.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Dec 2018 10:05:13 -0800 (PST) Subject: Re: [PATCH] aio: Convert ioctx_table to XArray To: Jeff Moyer , Matthew Wilcox Cc: Alexander Viro , Benjamin LaHaise , Andrew Morton , Kees Cook , linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dan Carpenter , kent.overstreet@gmail.com References: <20181128183531.5139-1-willy@infradead.org> <20181211175156.GF6830@bombadil.infradead.org> From: Jens Axboe Message-ID: <0f77a532-0d88-78bc-b9cc-06bb203a0405@kernel.dk> Date: Tue, 11 Dec 2018 11:05:12 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/11/18 11:02 AM, Jeff Moyer wrote: > Matthew Wilcox writes: > >> On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote: >>> I'm going to submit this version formally. If you're interested in >>> converting the ioctx_table to xarray, you can do that separately from a >>> security fix. I would include a performance analysis with that patch, >>> though. The idea of using a radix tree for the ioctx table was >>> discarded due to performance reasons--see commit db446a08c23d5 ("aio: >>> convert the ioctx list to table lookup v3"). I suspect using the xarray >>> will perform similarly. >> >> There's a big difference between Octavian's patch and mine. That patch >> indexed into the radix tree by 'ctx_id' directly, which was pretty >> much guaranteed to exhibit some close-to-worst-case behaviour from the >> radix tree due to IDs being sparsely assigned. My patch uses the ring >> ID which _we_ assigned, and so is nicely behaved, being usually a very >> small integer. > > OK, good to know. I obviously didn't look too closely at the two. > >> What performance analysis would you find compelling? Octavian's original >> fio script: >> >>> rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1 >>> blocksize=1024; numjobs=512; thread; loops=100 >>> >>> on an EXT2 filesystem mounted on top of a ramdisk >> >> or something else? > > I think the most common use case is a small number of ioctx-s, so I'd > like to see that use case not regress (that should be easy, right?). > Kent, what were the tests you were using when doing this work? Jens, > since you're doing performance work in this area now, are there any > particular test cases you care about? I can give it a spin, ioctx lookup is in the fast path, and for "classic" aio we do it twice for each IO... -- Jens Axboe