From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D09835EE8 for ; Thu, 23 Nov 2023 15:48:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="WJ+ze4VU" Received: from localhost (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by madras.collabora.co.uk (Postfix) with ESMTPSA id 5CBD966073C8; Thu, 23 Nov 2023 15:48:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1700754528; bh=HtHhhwKzqiAmW0q6ZmXEw8LmlFeUglATrn7z4cKTM9s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WJ+ze4VUzHRjNkBmb6lHmuf+Ebafd6xx5KUHZAu3ciKi8Z9HslrU7lKnm3FrQEMEJ fyrMpd2ysP8Smsy4P1xV+3HPvZNL0jnu3AG5vDnK7srtUsDj9JpEI/Ff+A76wKrReN FxOdklU12dId4ezpOa6L9wswuq/9XddLllvpFDET6066MKt5aA3UNZ+FXMuSlTleVU oYxVqNxTznf15TalnGYoESVFvVnaB5NPPDNaTjceLbQXy4ZLr7+QFpJUozDNPRr+Ar 3gIqMZTTwX0T4s63bOGd4qxMS4vBsscDDjlzhFen/tat7oN+lntrgfbHCX88V7FKk2 Q9nIo+TiEMpCw== Date: Thu, 23 Nov 2023 16:48:43 +0100 From: Boris Brezillon To: Jason Gunthorpe Cc: Robin Murphy , Joerg Roedel , iommu@lists.linux.dev, Will Deacon , linux-arm-kernel@lists.infradead.org, Rob Clark , Gaurav Kohli , Steven Price , Pasha Tatashin , Sean Christopherson , Alex Williamson , Joao Martins , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= Subject: Re: Light summary of LPC discussions on io page table Message-ID: <20231123164843.040a2c67@collabora.com> In-Reply-To: <20231123151118.GA436110@nvidia.com> References: <20231123151118.GA436110@nvidia.com> Organization: Collabora X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Jason, On Thu, 23 Nov 2023 11:11:18 -0400 Jason Gunthorpe wrote: > On Thu, Nov 23, 2023 at 09:51:41AM +0100, Boris Brezillon wrote: > > > Can these people please raise their voice here? Or maybe LPC's IOMMU > > discussions were summarized somewhere in an email sent to the IOMMU ML, > > where we could discuss that, instead of this thread. > > I think we are using session recordings mostly these days? I have a > bunch of people interested - I'm going to work to launch another group > project to tackle this. Maybe in Jan. > > The recordings are not broken up yet, but here is the master: > > https://www.youtube.com/live/vO2mAM8wOvU > > Pasha's talk is first at 2:21, and there was some discussion in the > room that may be hard to hear including the use of RCU and the > refcount. Pasha is interested in solving the memory waste his VFIO > application causes which is basically an algorithmic problem inside > the io page table. There was also some side discussion about > optimizations. mm implements a batch free technique that could apply > here too, and a batch alloc is also potentially interesting. > > My talk starts at 3:11 and we have another discussion later around > this issue in the context of dirty tracking optimization. Joao has > written and shared some code for what is concerning there in an > earlier email Sean C is the voice at the back sharing the KVM > learnings that getting to a common implementation is highly > recommended > > I had an interesting hallway discussion about a use case for bringing > back the old VFIO type 1.0 huge page split behavior and implementing > it in every enterprise iommu. > > Then we have this DRM need, which I've come to think of as a > guarenteed map without a table level allocate. > > These need touching all the "enterprise" focused page table > formats. There are so many now, doing the algorithm work 5-7 times is > not reasonable. A common radix algorithm and a more complex shared > implementation relying on RCU is the direction I want to head in. mm > shows a template how to achieve this, and I have some rough ideas to > explore. Thanks for pulling this together. I'll try to watch the video and make sense of what's explained there. I'll get back to you if I have questions. Regards, Boris 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 A4F88C61D97 for ; Thu, 23 Nov 2023 15:49:23 +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:MIME-Version:References:In-Reply-To: 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=kEAjJo6AtCEeBQ62RMCY04PRWyTrnJrBUT4C3gEkUzg=; b=bGiCLzBgFvNTJ2 b1H1nso8k97Am2ObTO81b5isQYg+13KzjvkHUC43AkqJ1ix3N5iHGLcC27n8qkTtuV5ivfR56BofC NTDl50tejA/W5pUAEuNkYNeiK+B39xnAlkcs3RBmdXDc3uIdJG6/Hb5vulvSsn/yiYCYtdKHHO3aE YRPrA3fW6K/OfBYdCoKLjJchX+yTxD1mCAc2BOuDj+a86c0Ricn5tuVtQNQvSg4rF3uIm0Pq0XCgK j724N7VL+buxRhKx1msTC0dT1+zwpreCqkLL7QHlQnuFJTTJhoxrQskMA68SCKaEpS5uaCFKyp6z5 sdul8m0iseZwOnotX9Yw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r6Bwi-005DTk-35; Thu, 23 Nov 2023 15:48:52 +0000 Received: from madras.collabora.co.uk ([46.235.227.172]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r6Bwg-005DSB-0S for linux-arm-kernel@lists.infradead.org; Thu, 23 Nov 2023 15:48:51 +0000 Received: from localhost (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by madras.collabora.co.uk (Postfix) with ESMTPSA id 5CBD966073C8; Thu, 23 Nov 2023 15:48:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1700754528; bh=HtHhhwKzqiAmW0q6ZmXEw8LmlFeUglATrn7z4cKTM9s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WJ+ze4VUzHRjNkBmb6lHmuf+Ebafd6xx5KUHZAu3ciKi8Z9HslrU7lKnm3FrQEMEJ fyrMpd2ysP8Smsy4P1xV+3HPvZNL0jnu3AG5vDnK7srtUsDj9JpEI/Ff+A76wKrReN FxOdklU12dId4ezpOa6L9wswuq/9XddLllvpFDET6066MKt5aA3UNZ+FXMuSlTleVU oYxVqNxTznf15TalnGYoESVFvVnaB5NPPDNaTjceLbQXy4ZLr7+QFpJUozDNPRr+Ar 3gIqMZTTwX0T4s63bOGd4qxMS4vBsscDDjlzhFen/tat7oN+lntrgfbHCX88V7FKk2 Q9nIo+TiEMpCw== Date: Thu, 23 Nov 2023 16:48:43 +0100 From: Boris Brezillon To: Jason Gunthorpe Cc: Robin Murphy , Joerg Roedel , iommu@lists.linux.dev, Will Deacon , linux-arm-kernel@lists.infradead.org, Rob Clark , Gaurav Kohli , Steven Price , Pasha Tatashin , Sean Christopherson , Alex Williamson , Joao Martins , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= Subject: Re: Light summary of LPC discussions on io page table Message-ID: <20231123164843.040a2c67@collabora.com> In-Reply-To: <20231123151118.GA436110@nvidia.com> References: <20231123151118.GA436110@nvidia.com> Organization: Collabora X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231123_074850_309544_CF7DA1E0 X-CRM114-Status: GOOD ( 28.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 Hi Jason, On Thu, 23 Nov 2023 11:11:18 -0400 Jason Gunthorpe wrote: > On Thu, Nov 23, 2023 at 09:51:41AM +0100, Boris Brezillon wrote: > > > Can these people please raise their voice here? Or maybe LPC's IOMMU > > discussions were summarized somewhere in an email sent to the IOMMU ML, > > where we could discuss that, instead of this thread. > > I think we are using session recordings mostly these days? I have a > bunch of people interested - I'm going to work to launch another group > project to tackle this. Maybe in Jan. > > The recordings are not broken up yet, but here is the master: > > https://www.youtube.com/live/vO2mAM8wOvU > > Pasha's talk is first at 2:21, and there was some discussion in the > room that may be hard to hear including the use of RCU and the > refcount. Pasha is interested in solving the memory waste his VFIO > application causes which is basically an algorithmic problem inside > the io page table. There was also some side discussion about > optimizations. mm implements a batch free technique that could apply > here too, and a batch alloc is also potentially interesting. > > My talk starts at 3:11 and we have another discussion later around > this issue in the context of dirty tracking optimization. Joao has > written and shared some code for what is concerning there in an > earlier email Sean C is the voice at the back sharing the KVM > learnings that getting to a common implementation is highly > recommended > > I had an interesting hallway discussion about a use case for bringing > back the old VFIO type 1.0 huge page split behavior and implementing > it in every enterprise iommu. > > Then we have this DRM need, which I've come to think of as a > guarenteed map without a table level allocate. > > These need touching all the "enterprise" focused page table > formats. There are so many now, doing the algorithm work 5-7 times is > not reasonable. A common radix algorithm and a more complex shared > implementation relying on RCU is the direction I want to head in. mm > shows a template how to achieve this, and I have some rough ideas to > explore. Thanks for pulling this together. I'll try to watch the video and make sense of what's explained there. I'll get back to you if I have questions. Regards, Boris _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel