From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged Date: Thu, 17 Jan 2019 16:51:44 +1200 Message-ID: References: <5c3e7de6.1c69fb81.4aebb.3fec@mx.google.com> <9E337EA6-7CDA-457B-96C6-E91F83742587@amacapital.net> <20190116054613.GA11670@nautica> <20190116213708.GN6310@bombadil.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20190116213708.GN6310@bombadil.infradead.org> Sender: linux-kernel-owner@vger.kernel.org To: Matthew Wilcox Cc: Jiri Kosina , Dominique Martinet , Andy Lutomirski , Josh Snyder , Dave Chinner , Jann Horn , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , Linux-MM , kernel list , Linux API List-Id: linux-api@vger.kernel.org On Thu, Jan 17, 2019 at 9:37 AM Matthew Wilcox wrote: > > Your patch 3/3 just removes the test. Am I right in thinking that it > doesn't need to be *moved* because the existing test after !PageUptodate > catches it? That's the _hope_. That's the simplest patch I can come up with as a potential solution. But it's possible that there's some nasty performance regression because somebody really relies on not even triggering read-ahead, and we might need to do some totally different thing. So it may be that somebody has a case that really wants something else, and we'd need to move the RWF_NOWAIT test elsewhere and do something slightly more complicated. As with the mincore() change, maybe reality doesn't like the simplest fix... > Of course, there aren't any tests for RWF_NOWAIT in xfstests. Are there > any in LTP? RWF_NOWAIT is actually _fairly_ new. It was introduced "only" about 18 months ago and made it into 4.13. Which makes me hopeful there aren't a lot of people who care deeply. And starting readahead *may* actually be what a RWF_NOWAIT read user generally wants, so for all we know it might even improve performance and/or allow new uses. With the "start readahead but don't wait for it" semantics, you can have a model where you try to handle all the requests that can be handled out of cache first (using RWF_NOWAIT) and then when you've run out of cached cases you clear the RWF_NOWAIT flag, but now the IO has been started early (and could overlap with the cached request handling), so then when you actually do a blocking version, you get much better performance. So there is an argument that removing that one RWF_NOWAIT case might actually be a good thing in general, outside of the "don't allow probing the cache without changing the state of it" issue. But that's handwavy and optimistic. Reality is often not as accomodating ;) Linus