Date: Fri, 12 Jun 2015 17:42:12 -0500 From: Alan Cox <alc@rice.edu> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, arch@FreeBSD.org Subject: Re: more strict KPI for vm_pager_get_pages() Message-ID: <557B6044.7060103@rice.edu> In-Reply-To: <20150612204442.GL73119@glebius.int.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?557B6044.7060103>