From owner-freebsd-arch@FreeBSD.ORG Fri Jun 12 22:42:22 2015 Return-Path: Delivered-To: arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD7E05CC; Fri, 12 Jun 2015 22:42:21 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4D0AF6F; Fri, 12 Jun 2015 22:42:21 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id t5CMgDcC014168; Fri, 12 Jun 2015 17:42:13 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp2.rice.edu with ESMTP id 1v01su8add-1; Fri, 12 Jun 2015 17:42:13 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 457064C02AD; Fri, 12 Jun 2015 17:42:13 -0500 (CDT) Message-ID: <557B6044.7060103@rice.edu> Date: Fri, 12 Jun 2015 17:42:12 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Gleb Smirnoff CC: Konstantin Belousov , arch@FreeBSD.org Subject: Re: more strict KPI for vm_pager_get_pages() References: <20150430142408.GS546@nginx.com> <20150506114549.GS34544@FreeBSD.org> <20150610183047.GT2499@kib.kiev.ua> <20150610184251.GP73119@glebius.int.ru> <20150611024706.GW2499@kib.kiev.ua> <20150611103743.GV73119@glebius.int.ru> <20150612040959.GB2080@kib.kiev.ua> <557B3311.40908@rice.edu> <20150612204442.GL73119@glebius.int.ru> In-Reply-To: <20150612204442.GL73119@glebius.int.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=5.98132654516803e-13 kscore.compositescore=7.64885099702184e-10 circleOfTrustscore=0 compositescore=0.601496849000349 suspectscore=10 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.601496849000349 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.00149684900034924 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506120395 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 22:42:22 -0000 On 06/12/2015 15:44, Gleb Smirnoff wrote: > Alan, > > [cc arch@ back] > > On Fri, Jun 12, 2015 at 02:29:21PM -0500, Alan Cox wrote: > A> I'm fine with changing the rules or expectations concerning the > A> *requested* page. In fact, there are inconsistencies among the call= ers > A> in whether they believe that the requested page could disappear.=20 > A> Specifically, some callers (e.g., kern_exec.c) handle the possibilit= y of > A> the requested page disappearing and treat its disappearance as an I/= O > A> error, while other callers (e.g., tmpfs_subr.c) would crash if the > A> requested disappeared. Since we also expect the requested page to > A> remain busy until we return to the caller, I don't see the point in > A> handling the possibility that the requested page disappeared. In ot= her > A> words, error or no error, the request page remains allocated and bus= y; > A> moreover, we guarantee that the array entry references the correct p= age. > A>=20 > A> On the other hand, I'm not ready to make a guarantee about the state= of > A> the array entries for the non-request pages. In the general case, t= he > A> I/O completion handlers will unbusy and place the pages in a paging > A> queue. So, in principle, they could be reclaimed before control was= > A> returned to vm_pager_get_pages()'s caller, and even if the pager upd= ated > A> the array entries, they would no longer be valid. For example, the = page > A> daemon could reclaim them, or another thread could simply decide to = free > A> them for some arbitrary reason. > A>=20 > A> In a nutshell, I'm fine with all of the changes except the one to > A> vm_thread_swapin(). The change to vm_thread_swapin() is only safe > A> because the pages have been wired and the pages are used in a partic= ular > A> way, i.e., the implementation of a thread stack. > > Replying to the last two paragraphs: > > Yes, and this lack of guarantee is the inconsistency, that I'd like to > address. The patch committed is only a first step of a bigger > vm_pager_get_pages KPI strictening. > > Let's get back to the patch that started this topic: > > https://lists.freebsd.org/pipermail/freebsd-arch/2015-April/017154.html= > I'm not sure that I understand what inconsistency you're referring to here. That the request page is handled differently from the non-request pages? Again, I'm happy with the changes to the handling of the request page.=20 However, I'm still on the fence about the other proposed changes, and I feel like the change to vm_thread_swapin() in the patch we are discussing is qualitatively different from the other changes in that same patch. In particular, it is the only part of that patch that touches non-request pages. As such, I didn't think it belongs.