Date: Fri, 12 Jun 2015 23:44:42 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Alan Cox <alc@rice.edu> Cc: Konstantin Belousov <kostikbel@gmail.com>, arch@FreeBSD.org Subject: Re: more strict KPI for vm_pager_get_pages() Message-ID: <20150612204442.GL73119@glebius.int.ru> In-Reply-To: <557B3311.40908@rice.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 callers A> in whether they believe that the requested page could disappear. A> Specifically, some callers (e.g., kern_exec.c) handle the possibility 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 other A> words, error or no error, the request page remains allocated and busy; A> moreover, we guarantee that the array entry references the correct page. A> 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, the 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 updated 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> 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 particular 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 -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150612204442.GL73119>