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=-5.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 1A51DC47E48 for ; Thu, 26 Sep 2019 12:03:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E5C2D2053B for ; Thu, 26 Sep 2019 12:03:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=shipmail.org header.i=@shipmail.org header.b="FPTUu1yg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726273AbfIZMD0 (ORCPT ); Thu, 26 Sep 2019 08:03:26 -0400 Received: from ste-pvt-msa2.bahnhof.se ([213.80.101.71]:42318 "EHLO ste-pvt-msa2.bahnhof.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725815AbfIZMDZ (ORCPT ); Thu, 26 Sep 2019 08:03:25 -0400 Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTP id 7CA553F5D5; Thu, 26 Sep 2019 14:03:23 +0200 (CEST) Authentication-Results: ste-pvt-msa2.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b=FPTUu1yg; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Authentication-Results: ste-ftg-msa2.bahnhof.se (amavisd-new); dkim=pass (1024-bit key) header.d=shipmail.org Received: from ste-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (ste-ftg-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki1CKtPzyZxv; Thu, 26 Sep 2019 14:03:20 +0200 (CEST) Received: from mail1.shipmail.org (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) (Authenticated sender: mb878879) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id 06B6E3F234; Thu, 26 Sep 2019 14:03:19 +0200 (CEST) Received: from localhost.localdomain (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) by mail1.shipmail.org (Postfix) with ESMTPSA id BD293360311; Thu, 26 Sep 2019 14:03:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1569499399; bh=DBvNfkxnIXmlXQ6kopNE8+KbXVhg4FkNygEe8p6ktTI=; h=Subject:From:To:References:Cc:Date:In-Reply-To:From; b=FPTUu1ygkAdtznT+rTStt02Vx5rZ4tXicv+4o1vN/kqhsRcZFdwmjZKWWCOG/7dBP VmbWEkLDh6EA8v6nrUzR7e7sXiUcgYjowzQXLT0wJUe9g0uI2v4Ie682IF1HDvGu1N 3I3x4TVh79sEl0EOse91dMG5/aZkvEqj9hjq04+M= Subject: Ack to merge through DRM? WAS Re: [PATCH v2 1/5] mm: Add write-protect and clean utilities for address space ranges From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28VMware=29?= To: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Andrew Morton , Matthew Wilcox References: <20190926115548.44000-1-thomas_os@shipmail.org> <20190926115548.44000-2-thomas_os@shipmail.org> Cc: Linus Torvalds Organization: VMware Inc. Message-ID: <85e31bcf-d3c8-2fcf-e659-2c9f82ebedc7@shipmail.org> Date: Thu, 26 Sep 2019 14:03:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190926115548.44000-2-thomas_os@shipmail.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/26/19 1:55 PM, Thomas Hellström (VMware) wrote: > From: Thomas Hellstrom > > Add two utilities to a) write-protect and b) clean all ptes pointing into > a range of an address space. > The utilities are intended to aid in tracking dirty pages (either > driver-allocated system memory or pci device memory). > The write-protect utility should be used in conjunction with > page_mkwrite() and pfn_mkwrite() to trigger write page-faults on page > accesses. Typically one would want to use this on sparse accesses into > large memory regions. The clean utility should be used to utilize > hardware dirtying functionality and avoid the overhead of page-faults, > typically on large accesses into small memory regions. > > Cc: Andrew Morton > Cc: Matthew Wilcox > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Rik van Riel > Cc: Minchan Kim > Cc: Michal Hocko > Cc: Huang Ying > Cc: Souptick Joarder > Cc: "Jérôme Glisse" > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Thomas Hellstrom > Reviewed-by: Ralph Campbell > --- Hi! I wonder if I can get an ack from an mm maintainer to merge this through DRM along with the vmwgfx patches? Andrew? Matthew? Thanks, Thomas