From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224sLG6m9L/BKLr9hG+InSTp5VPsgFmpYOWGDN0VUYo3/3xvZ9Twi5PP10h6aHl+lcqjr6TQ ARC-Seal: i=1; a=rsa-sha256; t=1516414377; cv=none; d=google.com; s=arc-20160816; b=lFkfX1wBfpbH1Ld3kScSI1XZO4aMRCRf0Q1QMQ7DDV04lYpwQ/56PkBeyTCwGX/FlP mfmmMdsFBmWuLWUEONQcBtDzLHV2d/tvFz+Ck+jCwn3Bq8E1/C4OCfSTk1invr9bLn7N 0wwdjuBgqtH55+9kjmLIpS39UBVA0WJXqjUkBMJJi9nFykAPjSljG8CQrMnQ+s19UKcq oBDtf9JbPOe9BxZzukkmBOFp0CDrEl7S31i7cbQrY+TrWpuQfxbNBAXsfrltYf9n7tpN T5j1+4xjaSQyLfnv179YYJZILriQdItIigzV2mVOOJLWcM/b4Gb0E9PYzkuAMQSfxY4H IdEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:arc-authentication-results; bh=nBz5ZtYYmNQb5pp62iFvQWNPrCluutz2+RfTkC2xE4M=; b=nPQFjxjXlVFzQR+6CIU5+GoDsAp9/7JmSYFG8vL1rO0EqYYfnuHxKY/t6jhCbCcKHp XLMq9eA/oIdKjtsLuwbJDHQcvIRdvnYt/RbTWDrN6G4F9hOwXj1efSaKKBFNLL58SXUX ew6zU1huKPdpqbNpCU54ODJ/+NFYhCwLVBPBX20BFc1P/kNAByihRLy/eg7RALKuhVFV mAmBgZG6yBHpByBGqmps4k5o/YOR89NDzO5Avb2FWkn1+T1EdNw0hBkV+gP+QIYJE/cP JhZtzLQfGFPWYfM7EA8SZ4zgBU+fHYLAxwiziYdx/tzkFdYgq5w8IJwK47M3Ow8/8pk+ YWWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of cl@linux.com designates 2001:558:fe21:29:69:252:207:41 as permitted sender) smtp.mailfrom=cl@linux.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of cl@linux.com designates 2001:558:fe21:29:69:252:207:41 as permitted sender) smtp.mailfrom=cl@linux.com Date: Fri, 19 Jan 2018 20:12:55 -0600 (CST) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Henry Willard 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 Subject: Re: [PATCH] mm: numa: Do not trap faults on shared data section pages. In-Reply-To: <2BEFC6DE-7A47-4CB9-AAE5-CEF70453B46F@oracle.com> Message-ID: 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> <2BEFC6DE-7A47-4CB9-AAE5-CEF70453B46F@oracle.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1740495615-1516414375=:14056" X-CMAE-Envelope: MS4wfPLsobVOwyAvtlGnQ10XgKwTLHbrSE2gtQpVimp3eW9ly+9mfy28tBJ369vcknL6uVMp7VcWhopciI7VPNdm+r5TbUf1MI+CDdl1eqsTxazX1rQBG3MD zbuhQhL2zOI5ClUTnYu+dcFKAV+GygleKpHpKLQ2rW+u1+VL+AgBOIENK6JLAT1QheKn+jC+qPjqRyL6N5HH/R5RXhRCdOTFhlsow44n0sC1UlkceJ4EW9DZ B/j9OUP6TjSNWzbXK5g4a4qxixYYS5skxkqWOYstKa21fG4Y5GcOWvTrQS3KXDKxequLQNM6HNdQ+lLgco6HGcTviYAQ64fUR6Rvd2HgVSfqCXXAZHGjUJzr phy66/TzTBf42eOBSTbhWhCdb6gttmiXCwsjDIP6Yq72qRMhVCCRb3QXmdFsdWas4OvoR1ZY9mUl2ZKNdiBshkYjXBTnM/zCE3MLs5h0EO3hwROw8TejPORE Lk0SJyCabVcn2Aknrf6kQgNKo0y9s/y5XXLFT6tDqQazJd+NW9p3+3UHQb9HsIm5duljGOtN4u0aFf/n3Kv3Oda0IHejLneuI6NB+SLrkxbNnZRuJez4C2FJ qgt8vCAConXJRTbdxFZurChg X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589778616343155985?= X-GMAIL-MSGID: =?utf-8?q?1590075721760399751?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1740495615-1516414375=:14056 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Thu, 18 Jan 2018, Henry Willard wrote: > If MPOL_MF_LAZY were allowed and specified things would not work > correctly. change_pte_range() is unaware of and can’t honor the > difference between MPOL_MF_MOVE_ALL and MPOL_MF_MOVE. Not sure how that relates to what I said earlier... Sorry. > > 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’t > understand why it would be desirable to modify the behavior via sysfs. I think the most common case of shared pages occurs for pages that contain code. In that case a page may be mapped into hundreds if not thousands of processes. In particular that is often the case for basic system libraries like the c library which may actually be mapped into every binary that is running. It is very difficult and expensive to unmap these pages from all the processes in order to migrate them. So some sort of limit would be useful to avoid unnecessary migration attempts. One example would be to forbid migrating pages that are mapped in more than 5 processes. Some sysctl know would be useful here to set the boundary. Your patch addresses a special case here by forbidding migration of any page mapped by more than a single process (mapcount !=1). That would mean f.e. that the complete migration of a set of processes that rely on sharing data via a memory segment is impossible because those shared pages can never be moved. By setting the limit higher that migration would still be possible. Maybe we can set that limit by default at 5 and allow a higher setting if users have applications that require a higher mapcoun? F.e. a common construct is a shepherd task and N worker threads. If those tasks each have their own address space and only communicate via a shared data segment then one may want to set the limit higher than N in order to allow the migration of the group of processes. --8323329-1740495615-1516414375=:14056--