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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C5248C61DF7 for ; Thu, 23 Nov 2023 13:48:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=J7aOJjTrhvu3eG+nDf9GOkzM3IRBY61rVg74Y1Oz5qw=; b=DVVOpkyDLQPn8z EWUzT9Yfi5F9lzjyodm4iFIjl83Pi55CmLzVI7IZNWnocxObW6Rbvalgl5VobtK5W0DbzTcCeIza8 fR+thBhsZzCYVfeKRQLpaWbefkWU5TlL3ra7g5jfvJkd+E+ykNzoT05qI0EMgFnMYBk5y9n8wKSoE WC1lfT6fwDR6omLd4mejyd6k0m2Aqnn8vslPGcar6fNy1ZZQ3UYgz5/097kosNy4mkzIRYrJKpFzM vsinDc5SzMosaVz51bL5QtJgav+RnWJv12l7ycYzQLIzLT5/5e2BYHZ1ExYlLYk/StqbJ1dBNXZkZ QMrhRQaqR8gfbniwa+Hg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r6A3s-004wM5-2g; Thu, 23 Nov 2023 13:48:08 +0000 Received: from mail-oa1-x2a.google.com ([2001:4860:4864:20::2a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r6A3p-004wLF-2D for linux-arm-kernel@lists.infradead.org; Thu, 23 Nov 2023 13:48:07 +0000 Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-1f938932bf0so550822fac.3 for ; Thu, 23 Nov 2023 05:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1700747282; x=1701352082; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=eBcUL3xU2f0NaCIYl2Pv/j1l+vUYG7PgqQlNoIpc8KA=; b=EKoNKQxsfUQ+XZbZoJY+CkNj3maVYHQBLB0/2neWN2F8Aqt8MkC7xZe58tGv+/VMrB OXYiztw6xb2FCsNGqD45yTiydxeW3fpMfXAWji///rTrrru+xKAF5e2XzEEMIv6M+K59 50qyWExrwModoUpBD/z1oGIjIAqg9lMg++LbQiYadYUgADK4jg68eSAPoDzsO5sygzVZ NT/mcIHSgCF7xh6ocheHOj4SfoWQB3vaIjX9lLeyV/K21qXvKYGPqgFTMEUIfAt90zCP qvd0YJrHvzJjq8OOEiZ98KupbN7cc7Ol5ST9LW2jonnmiEirzTd9O6ODb5+Rl57SgCm/ hpEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700747282; x=1701352082; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eBcUL3xU2f0NaCIYl2Pv/j1l+vUYG7PgqQlNoIpc8KA=; b=OKPH4LeIWjeWSqxHGf2duxSxk3Tzf6nbwG+nAa3uIs+qj3O7MjpBHPfJjZqtU9n/+A fiqUuGOuUFzefkyK10TE+GNi4wCeMxOyDEbqIUwHvrm1N788s36jU9G6s2XGSOOfZ6He HJ3BHdsjuLR091dT4zTHpBf0mJuFudxypaxaQl3iSeXKcd7Bz1uw1VwvhEvfRv7YSjOR PZdBCeDvwUtuWHmfIBE2PDkNRe9EZDNT05UJZWL9wdn6PkXZrMv3jx324CLDvRpq6Qb0 Zhif4pHBkRf+ri0hMKpmbiDDokT+mRXLh/WKYTH+5DW/nzH4J5BFYKFG52ny/PK8en9/ Iovg== X-Gm-Message-State: AOJu0Ywj53YTqIhX2dNnycWH65putTevcdZFKFGbxUzekCrh1RHb1fy1 Hj64voZ5zDYhgcqCQMfhttMCSw== X-Google-Smtp-Source: AGHT+IG3ya4ejxAoN/ar5HRnd4khJpq3S9+hTgdc146tuu02dCv5hm94uer6aYKwFjxgH7PaV3Kn8Q== X-Received: by 2002:a05:6870:280a:b0:1ef:cedd:5c32 with SMTP id gz10-20020a056870280a00b001efcedd5c32mr7008672oab.3.1700747282615; Thu, 23 Nov 2023 05:48:02 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-134-23-187.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.134.23.187]) by smtp.gmail.com with ESMTPSA id pn9-20020a056871d30900b001eace5491c8sm296827oac.18.2023.11.23.05.48.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Nov 2023 05:48:01 -0800 (PST) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1r6A3k-001op5-Ip; Thu, 23 Nov 2023 09:48:00 -0400 Date: Thu, 23 Nov 2023 09:48:00 -0400 From: Jason Gunthorpe To: Boris Brezillon Cc: Robin Murphy , Joerg Roedel , iommu@lists.linux.dev, Will Deacon , linux-arm-kernel@lists.infradead.org, Rob Clark , Gaurav Kohli , Steven Price Subject: Re: [PATCH v2 0/2] iommu: Allow passing custom allocators to pgtable drivers Message-ID: <20231123134800.GA432016@ziepe.ca> References: <20231113101103.1cc05c8c@collabora.com> <20231120140425.GA10140@ziepe.ca> <20231120153838.2166e7b8@collabora.com> <20231120144604.GD10140@ziepe.ca> <20231120161418.5eca178e@collabora.com> <20231120154536.GE10140@ziepe.ca> <6e74bd37-9e10-416e-9fbd-0cebb7948e2b@arm.com> <20231122175055.GI10140@ziepe.ca> <20231123095141.19dc26d6@collabora.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231123095141.19dc26d6@collabora.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231123_054806_050477_931D8944 X-CRM114-Status: GOOD ( 29.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Nov 23, 2023 at 09:51:41AM +0100, Boris Brezillon wrote: > Beside, I think your objection that custom allocators are in the way of > this caching generalization is a bit of an over statement, especially if > custom allocators provide the same guarantees you get from existing > allocations (page-backed, no fields used in the page, etc). Worst case > scenario, you disable the generic cache for all users that pass a custom > allocator, and add a pr_warn() (or WARN_ON() if you want to be pushy) > to make sure driver owners take that into consideration quickly. I want to have common algorithms to manage the radix system, like mm does, and then have some fairly hairy stuff done in the new common code to address all the needs we now understand people have. This is not just "caching". One of the important things on this list is RCU freeing of the table memory. RCU freeing requires precious space in the struct page. External ops mean we must have the io page table instance available inside the RCU callback so it knows what op to call to free. This means the struct page needs to store both a rcu_head and another pointer. Currently the similar page table algorithms in the mm side consume all the free struct page space. I don't expect the future io page table version of the same stuff to be much different. So it is not just that the allocator side can't use the struct page memory. It is that an external allocator inherently demands *more* space in the struct page, space we may not have to give. Worse, the entire idea of RCU free seems to be incompatible with what you are trying to achieve since pages could be unavailable for use while they are waiting in RCU. I'm looking at this and thinking we loose the option to do RCU in the generic code to accommodate external ops. "make RCU optional" is basically saying to duplicate alot of stuff because RCU becomes pretty fundamental to features and algorithm design. Do you understand my alarm to this direction better now? I'm sorry if I haven't explained this clearly enough. (I'm coming at this from the MM perspective where the sorts of algorithms and problems here are already well known) > unresponsive and reluctant to change how they use the APIs. So, if I > follow your way of thinking, you'll just be stuck in the same place, > waiting for DRM drivers to accept the transversal changes you intend to > push. I wasn't imagining a forced API change. I think the current API can work fine along with an optional pre-allocation scheme. > What I strongly oppose to though, is having someone say 'I have the > perfect solution for you', and then tell me, 'but you have to wait > another six months, maybe more, to see what it looks like'. I never said you should be blocked. I agreed with duplicating if necessary to be unblocked. I also outlined and encouraged you to solve the general problem, but I fully understand you don't want to take it on. That's fine too. You are both mis-characterizing my position as trying to block the DRM driver :( I'm trying to accomodate the work I see we need to do soon on the enterprise iommu side that touches this same code. Look, if we go down this road then we may end up duplicating the page table code so the iommu drivers can use the improved versions until the DRM driver can be changed. Maybe doing duplication later is better than sooner. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel