From owner-svn-src-all@freebsd.org Fri Oct 9 04:31:02 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDDEA9D14E1; Fri, 9 Oct 2015 04:31:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AF464D4E; Fri, 9 Oct 2015 04:31:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t994V0EJ096304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Oct 2015 21:31:00 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t994UxmQ096303; Thu, 8 Oct 2015 21:30:59 -0700 (PDT) (envelope-from jmg) Date: Thu, 8 Oct 2015 21:30:59 -0700 From: John-Mark Gurney To: Alan Cox Cc: John Baldwin , Mark Johnston , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r288431 - in head/sys: kern sys vm Message-ID: <20151009043059.GK67524@funkthat.com> References: <201509302306.t8UN6UwX043736@repo.freebsd.org> <1837187.vUDrWYExQX@ralph.baldwin.cx> <20151002045842.GA18421@raichu> <4276391.z2UvhhORjP@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 08 Oct 2015 21:31:00 -0700 (PDT) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 04:31:02 -0000 Alan Cox wrote this message on Fri, Oct 02, 2015 at 18:50 -0500: > On Oct 2, 2015, at 10:59 AM, John Baldwin wrote: >=20 > > I think it is not unreasonble to expect that fadvise() incurs system-wi= de > > affects. A properly implemented WILLNEED that does read-ahead cannot w= ork > > without incurring system-wide effects. I had always assumed that fadvi= se() > > operated on a file, not a given process' view of a file (unlike, say, > > madvise which only operates on mappings and only indirectly affects > > file-backed data). >=20 >=20 > Can you elaborate on what you mean by ?I had always assumed that fadvise(= ) operated on a file, ??? >=20 > Under the previous implementation, if you did an fadvise(DONTNEED) on a f= ile, in order to cache the file?s pages, those pages first had to be unmapp= ed from any address space. (You can find this unmapping performed by vm_pa= ge_try_to_cache().) In other words, there was never any code that said, ?I= s this a mapped page, and if it is, don?t cache it because we?re actually p= erforming an fadvise().? So, to pick an extreme example, if you did an fad= vise(?libc.so?, DONTNEED), unless some process had libc.so wired, then ever= y single mapping to every single page of libc.so was going to be destroyed = and the pages moved to the cache. However, because we moved the pages to t= he cache (rather than freeing them), and libc.so is frequently accessed, a = subsequent instruction fetch would have faulted and been able to reactivate= the cached page, avoiding an I/O operation. In other words, that we were = caching the pages targeted by fadvise() rather than simply freeing them mat= tered in cases where the pages were in use/accessed by multiple processes. This would be a very nasty DoS if someone just ran fadvise('libc.so', DONTNEED) in loop, and forced any future accesses of libc.so to pull =66rom disk, over and over and over again... --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."