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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 202A8C001E0 for ; Thu, 27 Jul 2023 17:15:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232799AbjG0RPv (ORCPT ); Thu, 27 Jul 2023 13:15:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231218AbjG0RPf (ORCPT ); Thu, 27 Jul 2023 13:15:35 -0400 Received: from mail.codeweavers.com (mail.codeweavers.com [4.36.192.163]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 392453A89; Thu, 27 Jul 2023 10:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codeweavers.com; s=s1; h=From:Cc:To:Subject:Date:Message-ID:Sender; bh=qDGyNuZm1SlXvpHYjVnont8zJnpqBv3isL90u1ngU/Q=; b=eBXhTsEZvHyz459/k9nNsc+Ulj zsL16vMgaqJ18maqGw1TS+RsXBgyXVShSA335XoxyuV6e5Kw5UfGaAuN1Cl3PSi+bi+AqIqm8ziNd akly2EihEuPQ8MqrgTYkkpiPr5i2sx6WMFQj3d/elQR7eBafo0SZnIFPSFr+blNBZBR40gwfVOrWQ jkHCfYjX+cML0EEgKWVa7pFYDApTKP8hGiqnL6hWXM+02xPEp+6WjmxOzqsuHxHWhDa8131odgChs Dkhjdn7bZgqldhIznacSS/1YJcDd4f2yRZVkWThhNlPoGpmcNN3+djoaepg+lkJU/2XRd+ZGFYqq6 MjGxkbGg==; Received: from cw141ip123.vpn.codeweavers.com ([10.69.141.123]) by mail.codeweavers.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qP4aA-006l8N-1D; Thu, 27 Jul 2023 12:15:22 -0500 Message-ID: Date: Thu, 27 Jul 2023 11:15:13 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [v3] fs/proc/task_mmu: Implement IOCTL for efficient page table scanning To: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Cc: Muhammad Usama Anjum , "Kirill A. Shutemov" , =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Andrei Vagin , Danylo Mocherniuk , Alex Sierra , Alexander Viro , Andrew Morton , Axel Rasmussen , Christian Brauner , Cyrill Gorcunov , Dan Williams , David Hildenbrand , Greg KH , "Gustavo A . R . Silva" , "Liam R . Howlett" , Matthew Wilcox , Mike Rapoport , Nadav Amit , Pasha Tatashin , Peter Xu , Shuah Khan , Suren Baghdasaryan , Vlastimil Babka , Yang Shi , Yun Zhou , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, kernel@collabora.com References: <20230713101415.108875-6-usama.anjum@collabora.com> <7eedf953-7cf6-c342-8fa8-b7626d69ab63@collabora.com> <382f4435-2088-08ce-20e9-bc1a15050861@collabora.com> <44eddc7d-fd68-1595-7e4f-e196abe37311@collabora.com> <1afedab8-5929-61e5-b0da-9c70dc01c254@collabora.com> <94c6b665-bbc2-5030-f9b1-d933791008b8@codeweavers.com> Content-Language: en-GB From: Paul Gofman In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Windows GetWriteWatch won't work if the range is not withing a single memory view regardless of MEM_LARGE_PAGES (that is, single VirtualAlloc result, somewhat analogous to VMA but not quite), such a call will result in an error. For the context, Windows never auto splits or joins memory views, and basically nothing can be done across views boundary (merging placeholder views is an exception, while unrelated). VirtualProtect (which stands for mprotect) can be done for individual pages withing the view of course, but it is purely per page and doesn't affect view protection flags or result in any splitting of those. VirtualProtect across views adjacent in memory will also fail. On 7/27/23 05:18, Michał Mirosław wrote: > > Is it possible (on Windows) to have MEM_LARGE_PAGES allocation near a > normal one and run GetWriteWatch() on both in one call? If so, how > does it behave / what is expected? > > Best Regards > Michał Mirosław