Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4757584imu; Tue, 8 Jan 2019 05:55:56 -0800 (PST) X-Google-Smtp-Source: ALg8bN4VC9z6qj/Cgq8GCZOdrK1ko4woXUaSwQLSTGrkpqQZ+rgsNdV0D1uhuTSp8N5O9mIMp2rh X-Received: by 2002:a62:81c1:: with SMTP id t184mr1910212pfd.40.1546955755993; Tue, 08 Jan 2019 05:55:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546955755; cv=none; d=google.com; s=arc-20160816; b=hnr/c4rZ0dPKXyE83KxF565W/fjrb/U/NPyTgKViDawqFEj1OfnFPWJVAazmRexwP1 nhRtzD0R28HoXee61cieMo0aV+1jDzEDDN+/vSEd7UOBqUEaFn1RPmvygWFuqIaCPxSY JW2bpOrgYLUQWzc9JZWv42EEA33W1+vzOLu9CSI1d2tju00WVcdN6ydMrZpwFv8HPoi+ 2GAtBKxyHffXzEoRhxVDgWCixxaj9tdH2pHvi3Oajgkbc89HA6C2oNPm4jfAGi2BQaSH QkkMtWX6cML+eXSIEvrkOkBuWzhtiVML5FEaKoCwZvAS0WHlBjuNiMekHVd5X5NwSzW0 wbNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=IQDBgC0SZo11I6t8pkwNbm1JRlPP4UGUOnflve3eUao=; b=sYa8Ri+vd88zcfZk1zH8Z2m3RSKx3x9+c2AC6cuRFXc+aCDNyWI9ghJZ6VfA/41lJb TxF8fUaIsb7TVzSVrpDtjTZ1BW4P7Q3HqqHAZEaRzYcVcBEgtVOjWm4mjh4JzGUdm8+S XgShESjLOXn6Cijzt6q9g6G5Um1NHJwDFMWjaMXr9pAhKNUcs9F71UtOV9Ow/H5JKsLV toTj2HmcpvZ111vhavZvb0EKmyFfZpHkySc6HYTEmhRYJq2oeDQcNNn+jG8ZyyGRp6mJ R0b+75wOKbfsYl9bTINua+eiiNuT1Ma8+ezAcKbe2dtEHJiLVbCncKwHgre0SvDOE7n+ N0OA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v5si521529plg.318.2019.01.08.05.55.40; Tue, 08 Jan 2019 05:55:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728642AbfAHNyH (ORCPT + 99 others); Tue, 8 Jan 2019 08:54:07 -0500 Received: from esgaroth.petrovitsch.at ([78.47.184.11]:4664 "EHLO esgaroth.tuxoid.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728210AbfAHNyH (ORCPT ); Tue, 8 Jan 2019 08:54:07 -0500 Received: from thorin.petrovitsch.priv.at (80-110-99-3.cgn.dynamic.surfer.at [80.110.99.3]) (authenticated bits=0) by esgaroth.tuxoid.at (8.15.2/8.15.2) with ESMTPSA id x08Dr8lI011223 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Jan 2019 14:53:09 +0100 Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged To: Jiri Kosina Cc: Vlastimil Babka , Linus Torvalds , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org References: <047f0582-a4d3-490d-7284-48dfdf9e9471@petrovitsch.priv.at> From: Bernd Petrovitsch Message-ID: <8c9feac8-fecb-a56a-afaf-c1352a666991@petrovitsch.priv.at> Date: Tue, 8 Jan 2019 14:53:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-DCC-debian-Metrics: esgaroth.tuxoid.at 1169; Body=10 Fuz1=10 Fuz2=10 X-Virus-Scanned: clamav-milter 0.97 at esgaroth.tuxoid.at X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Report: * 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on esgaroth.tuxoid.at Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/01/2019 12:37, Jiri Kosina wrote: > On Tue, 8 Jan 2019, Bernd Petrovitsch wrote: > >> Shouldn't the application use e.g. mlock()/.... to guarantee no page >> faults in the first place? > > Calling mincore() on pages you've just mlock()ed is sort of pointless > though. Obviously;-) Sorry for being unclear above: If I want my application to avoid suffering from page faults, I use simply mlock() (and/or friends) to nail the relevant pages into physical RAM and not "look if they are out, if yes, get them in" which has also the risk that these important pages are too soon evicted again. But perhaps I'm missing some very special use cases .... MfG, Brend -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at