Received: by 10.223.185.116 with SMTP id b49csp438099wrg; Wed, 21 Feb 2018 00:38:03 -0800 (PST) X-Google-Smtp-Source: AH8x226y6HBP4l3ANK84WhFkrx+K534HKcwe4y2yFCOxCs5wkHdfynpJqqm+fmXwcU/b3oHcQ0SF X-Received: by 2002:a17:902:7445:: with SMTP id e5-v6mr2436820plt.204.1519202283522; Wed, 21 Feb 2018 00:38:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519202283; cv=none; d=google.com; s=arc-20160816; b=0ai8lsuFDw0HcLMx5BLdyqysrMmSUNWGXtdLxS0g8Xcvh8QL+KZm6GsMwE6+2crErZ qRBE1fvBbl2KYivMOEQ0kC9JSWGEx9/l9zYtDsomUUwlEB1GmlW7P9YvfVs6Ngg+UEiN gAHWGkUZDBgV4gJO8szUFWewTmWBatwheEQ61hD5IaWPHK3hvi8kpOvGObUdCeCUmIE5 Gv5OapNeAbs/IUbELs0FwOKURdtTnnUmMdDgX/FDondmhUXaGcHi46ndKnmRtVhXbmLO QP5ZfIdJvtHOIwX7r40zSeSbAZDUzNFbRE1NzMYdZJYgmlZWXv3A1/KL4x1vTgVS4pTw xXFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=GZxQXRUQiI/fCGu9hyNjwfX7ziFy/mmZG8tVPoLJncE=; b=TPLn/Ro/BaA4CCSF8l/BAmu9m1pdXDkZMBDei3dJbA6SFGbcIy0qOcP/HicUdn6548 0eCZyvODr+J88r/A3PV4LOGC+8HeMsjCGIJE+iBh+MIlKW2/W8I6Opm0T1TC3RmFUOtQ CBaR1jixe6a/xWrXUJlAs9xWY9IjN3jDOc4Tp0wWUbkJI1KC0jg/uqEwqV9tWF2lSqaj nCjJORGLLJB4HA8prpBxpxzgfLH1pGyWcl/G3Iv2luA46ZrcoxVsZyapIpcQwHlQyBAm 4oi7Lf6ailjFOEj9D0ZwmMyxlRAOqJ+rgUp7L6gcw/6rz19L7dc1/UpORVk2H9l73e5t JWLg== ARC-Authentication-Results: i=1; mx.google.com; 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 t137si568787pgb.736.2018.02.21.00.37.49; Wed, 21 Feb 2018 00:38:03 -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; 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 S1752419AbeBUIfF (ORCPT + 99 others); Wed, 21 Feb 2018 03:35:05 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:36441 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752335AbeBUIfE (ORCPT ); Wed, 21 Feb 2018 03:35:04 -0500 Received: from [37.80.9.43] by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1eoPo9-000133-KP; Wed, 21 Feb 2018 09:31:22 +0100 Date: Wed, 21 Feb 2018 09:34:57 +0100 (CET) From: Thomas Gleixner To: Mike Kravetz cc: Reinette Chatre , fenghua.yu@intel.com, tony.luck@intel.com, gavin.hindman@intel.com, vikas.shivappa@linux.intel.com, dave.hansen@intel.com, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core In-Reply-To: <2db87a79-e13f-ad6b-c399-1ad58585f38e@oracle.com> Message-ID: References: <6c960fc0-820e-757c-2770-d770647e63d6@intel.com> <2db87a79-e13f-ad6b-c399-1ad58585f38e@oracle.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 20 Feb 2018, Mike Kravetz wrote: > On 02/20/2018 03:21 PM, Thomas Gleixner wrote: > > The other problem is that we'd need to have MAP_CONTIG first so you > > actually can allocate physically contigous memory from user space. Mike is > > working on that, but it's not available today. The only way to do so today > > (with lots of waste) would be MAP_HUGETLB, which might be an acceptable > > constraint up to the point where MAP_CONTIG is available. > > Just to clarify, there is not any activity on exposing a general purpose > MAP_CONTIG interface to user space. When initially proposed, MAP_CONTIG > was shot down and the suggestion was to create a new in kernel interface > to make allocation of contiguous pages easier. The initial use case was > a driver which could use the new internal interface as part of it's > mmap() routine to give contiguous regions to user space. Thanks for the clarification. > Reinette is using this new interface, but that must be for the ?immediate > allocation? case you are trying to move away from. Sorry, I have not been > following development of this feature. > > If you would have to create a device to accept a user buffer, could you > perhaps use the same device to create/hand out a contiguous mapping? Yes, that's straight forward. Thanks, tglx