[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiqfAdmmE+pR3O5zs=xtkd6A6ShyyCwpwSZ+341L=zVYw@mail.gmail.com>
Date: Thu, 10 Jan 2019 23:11:23 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Dave Chinner <david@...morbit.com>, Jiri Kosina <jikos@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
Jann Horn <jannh@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg KH <gregkh@...uxfoundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Michal Hocko <mhocko@...e.com>, Linux-MM <linux-mm@...ck.org>,
kernel list <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Thu, Jan 10, 2019 at 8:58 PM Dominique Martinet
<asmadeus@...ewreck.org> wrote:
>
> I get on average over a few queries approximately a real time of 350ms,
> 230ms and 220ms immediately after drop cache and service restart, and
> 150ms, 60ms and 60ms after a prefetch (hand-wavy average over 3 runs, I
> didn't have the patience to do proper testing).
> (In both cases, user/sys are less than 10ms; I don't see much difference
> there)
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.
Linus
Powered by blists - more mailing lists