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 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C06C8C43387 for ; Fri, 11 Jan 2019 07:32:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 969C62146F for ; Fri, 11 Jan 2019 07:32:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729330AbfAKHcZ (ORCPT ); Fri, 11 Jan 2019 02:32:25 -0500 Received: from nautica.notk.org ([91.121.71.147]:56667 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727578AbfAKHcY (ORCPT ); Fri, 11 Jan 2019 02:32:24 -0500 Received: by nautica.notk.org (Postfix, from userid 1001) id CA660C01B; Fri, 11 Jan 2019 08:32:21 +0100 (CET) Date: Fri, 11 Jan 2019 08:32:06 +0100 From: Dominique Martinet To: Linus Torvalds Cc: Dave Chinner , Jiri Kosina , Matthew Wilcox , Jann Horn , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , Linux-MM , kernel list , Linux API Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged Message-ID: <20190111073206.GA1303@nautica> References: <20190109043906.GF27534@dastard> <20190110004424.GH27534@dastard> <20190110070355.GJ27534@dastard> <20190110122442.GA21216@nautica> <20190111045750.GA27333@nautica> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Linus Torvalds wrote on Thu, Jan 10, 2019: > But those numbers aren't about the mincore() change. That's just from > dropping caches. > > Now, what's the difference with the mincore change, and without? Is it > actually measurable? > > Because that's all that matters: is the mincore change something you > can even notice? Is it a big regression? > > The fact that things are slower when they are cold in the cache isn't > the issue. The issue is whether the change to mincore semantics makes > any difference to real loads. mincore itself isn't used to reload the data, but is necessary to know *what* you need to reload. If you don't know what pages are hot, how can you preload them? For small enough a database and with enough memory you can act stupid and load the whole tables in cache, that's what I did because I was lazy and only had a big mysql data set around. But the container warming up automaton Dave mentioned and postgresql db preloading with pgfincore explicitely depend on being able to tell what they need to preload. pgfincore documentation states: ---- set of PostgreSQL functions to manage blocks in memory Those functions let you know which and how many disk block from a relation are in the page cache of the operating system, and eventually write the result to a file. Then using this file, it is possible to restore the page cache state for each block of the relation. ---- If you cannot dump an arbitrary "hot state" x, you cannot restore it. This is all basically a repeat of the other subthread; sure precaching itself doesn't need mincore and if you're all-knowing the syscall isn't needed, but mere mortals need it. If it's about the commit itself, vmtouch tells me 0 page in these database files are in cache when I reboot to a 5.0-rc1 kernel and run some queries, so the difference after a fresh boot is exactly what I stated. I'm probably missing something but I'm not quite sure in what situation the "new mincore" has any use right now. -- Dominique Martinet | Asmadeus