more strict KPI for vm_pager_get_pages()

Alan Cox alc at rice.edu
Fri Jun 12 22:42:22 UTC 2015


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 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
>


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. 
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.





More information about the freebsd-arch mailing list