Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752799AbbD3SpL (ORCPT ); Thu, 30 Apr 2015 14:45:11 -0400 Received: from mail-la0-f50.google.com ([209.85.215.50]:36175 "EHLO mail-la0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752396AbbD3SpI (ORCPT ); Thu, 30 Apr 2015 14:45:08 -0400 MIME-Version: 1.0 In-Reply-To: <20150430132230.GE15874@node.dhcp.inet.fi> References: <20150429193622.GA11892@node.dhcp.inet.fi> <20150430132230.GE15874@node.dhcp.inet.fi> Date: Thu, 30 Apr 2015 19:45:06 +0100 Message-ID: Subject: Re: Regression: Requiring CAP_SYS_ADMIN for /proc//pagemap causes application-level breakage From: Mark Williamson To: "Kirill A. Shutemov" Cc: Konstantin Khlebnikov , Linus Torvalds , Mark Seaborn , kernel list , "Kirill A. Shutemov" , Pavel Emelyanov , Andrew Morton , Andy Lutomirski , Linux API , Finn Grimwood , Daniel James Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1032 Lines: 27 >> Something like this (see patch in attachment) > > THP is not covered. > > Any comments on kcmp() idea? It seems like a modified kcmp() would also be a valid approach but, as you noted, probably speed-limited for our purposes. As you say, there is the option of a vector-oriented equivalent. It seems like a generally nice facility to have available in the kernel but my suspicion is that it wouldn't be optimal for us... My thinking is that using soft-dirty might give us the best performance on platforms where it's available. We're only using fork() as a cunning/hacky way of tracking what pages change; soft-dirty would allow us to avoid that too, whereas using kcmp() would still require the forking overhead. Does that make sense, or have I missed something? Thanks, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/