From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBoszaHPDwVu9nQo9h2wvnQK4sAJn/BmYeryB2lz5xppa7t+MhNUQe67vik69FOar9wk9U9/+ ARC-Seal: i=1; a=rsa-sha256; t=1516324032; cv=none; d=google.com; s=arc-20160816; b=qPQpLLuW0y9ycw9W2JAcktxIK1k+PTA+USpwkHm3nplG+YVJt+/zqhSpMWESrsfxuV W2Qf+nahtM73+VPMphh+R89oksp3Pf83VwKrbHBuZyCiEE88shVIlOKRIa9HWwNTGXE1 ImfSKQy3o2A90KqKAyMYrhH9jiYIsQgtj7xpYKNFRBPEA+Xv4IlWEwX0wtRz5diSFDi8 gnEjQ7Sa9vPiDU9lKYP0i37Yo0tMfBQpw2RWz15dC32hMqZXsSUgaltySWtVEe5Y7Hqw ASL8WAPBO1aCCUcYH0hdLmHMgTI5vxzDHdEYr8CpAU2xrXoloAA049+f+cJQtRG0rld7 vdGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:dkim-signature :arc-authentication-results; bh=jsmGNCVJtjBzpMGxVVkrLyqghkNDoPa5JFgGITACOEk=; b=GDP1Amb8uTBjqb17nzkqObEdmc+J6wrC4JRPr6B6jYeFQ/We/PCDpzTs9gG0Df61dU 8aV+VWxJCVmG/HxnZX7hLEpRyLWmOZQhsLONLAbrKtRG5wndRGvUKfAIIb2YN+vZXKt1 VJOMgF2znXm6uybUEaZBnd9lMVE+T7NCXVAitMw2rDSTZXnXNdjUkcePWeQw78R+10Ca +ZGqCilFYN6Lb8XAvBV7aGc3Aas8oWTQ9S70wRUiYIyJtTgX3LOdr9vGuV+Zrc0xdRQn Gvqzo5aqXUpt1jacthBSer7HyvnXWj0p0wO7Xqfig2iRa9b9RHG1f+AnnVlUw3IXYZsC Vyfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=WFjpxqyT; spf=pass (google.com: domain of henry.willard@oracle.com designates 141.146.126.78 as permitted sender) smtp.mailfrom=henry.willard@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=WFjpxqyT; spf=pass (google.com: domain of henry.willard@oracle.com designates 141.146.126.78 as permitted sender) smtp.mailfrom=henry.willard@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [PATCH] mm: numa: Do not trap faults on shared data section pages. From: Henry Willard In-Reply-To: Date: Thu, 18 Jan 2018 17:06:54 -0800 Cc: Mel Gorman , akpm@linux-foundation.org, kstewart@linuxfoundation.org, zi.yan@cs.rutgers.edu, pombredanne@nexb.com, aarcange@redhat.com, gregkh@linuxfoundation.org, aneesh.kumar@linux.vnet.ibm.com, kirill.shutemov@linux.intel.com, jglisse@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <2BEFC6DE-7A47-4CB9-AAE5-CEF70453B46F@oracle.com> References: <1516130924-3545-1-git-send-email-henry.willard@oracle.com> <1516130924-3545-2-git-send-email-henry.willard@oracle.com> <20180116212614.gudglzw7kwzd3get@suse.de> To: Christopher Lameter X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8778 signatures=668654 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801190008 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589778616343155985?= X-GMAIL-MSGID: =?utf-8?q?1589980988425413155?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: > On Jan 17, 2018, at 10:23 AM, Christopher Lameter = wrote: >=20 > On Tue, 16 Jan 2018, Mel Gorman wrote: >=20 >> My main source of discomfort is the fact that this is permanent as = two >> processes perfectly isolated but with a suitably shared COW mapping >> will never migrate the data. A potential improvement to get the = reported >> bandwidth up in the test program would be to skip the rest of the VMA = if >> page_mapcount !=3D 1 in a COW mapping as it would be reasonable to = assume >> the remaining pages in the VMA are also affected and the scan is = wasteful. >> There are counter-examples to this but I suspect that the full VMA = being >> shared is the common case. Whether you do that or not; >=20 > Same concern here. Typically CAP_SYS_NICE will bypass the check that = the > page is only mapped to a single process and the check looks exactly = like > the ones for manual migration. Using CAP_SYS_NICE would be surprising > here since autonuma is not triggered by the currently running process. >=20 > Can we configure this somehow via sysfs? If I understand the code correctly, CAP_SYS_NICE allows MPOL_MF_MOVE_ALL = to be set with mbind() or used with move_pages(). CAP_SYS_NICE also = causes migrate_pages() to behave as if MPOL_MF_MOVE_ALL were specified. = There are checks requiring either MPOL_MF_MOVE_ALL or = page_mapcount(page) =3D=3D 1. The normal case does not call = change_prot_numa(). change_prot_numa() is only called when MPOL_MF_LAZY = is specified, and at the moment MPOL_MF_LAZY is not recognized as a = valid flag. It looks to me that as things stand now, change_prot_numa() = is only called from task_numa_work(). If MPOL_MF_LAZY were allowed and specified things would not work = correctly. change_pte_range() is unaware of and can=E2=80=99t honor the = difference between MPOL_MF_MOVE_ALL and MPOL_MF_MOVE.=20 For the case of auto numa balancing, it may be undesirable for shared = pages to be migrated whether they are also copy-on-write or not. The = copy-on-write test was added to restrict the effect of the patch to the = specific situation we observed. Perhaps I should remove it, I don=E2=80=99= t understand why it would be desirable to modify the behavior via sysfs. Thanks, Henry >=20 >=20