Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Jun 2015 14:31:00 +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:  <20150615113100.GW73119@glebius.int.ru>
In-Reply-To: <557B6044.7060103@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> <20150612204442.GL73119@glebius.int.ru> <557B6044.7060103@rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
  Alan,

On Fri, Jun 12, 2015 at 05:42:12PM -0500, Alan Cox wrote:
A> > A> On the other hand, I'm not ready to make a guarantee about the state of
A> > A> the array entries for the non-request pages.  In the general case, the
A> > A> I/O completion handlers will unbusy and place the pages in a paging
A> > A> queue.  So, in principle, they could be reclaimed before control was
A> > A> returned to vm_pager_get_pages()'s caller, and even if the pager updated
A> > A> the array entries, they would no longer be valid.  For example, the page
A> > A> daemon could reclaim them, or another thread could simply decide to free
A> > A> them for some arbitrary reason.
A> > A> 
A> > A> In a nutshell, I'm fine with all of the changes except the one to
A> > A> vm_thread_swapin().  The change to vm_thread_swapin() is only safe
A> > A> because the pages have been wired and the pages are used in a particular
A> > A> way, i.e., the implementation of a thread stack.
A> >
A> > Replying to the last two paragraphs:
A> >
A> > Yes, and this lack of guarantee is the inconsistency, that I'd like to
A> > address. The patch committed is only a first step of a bigger
A> > vm_pager_get_pages KPI strictening.
A> >
A> > Let's get back to the patch that started this topic:
A> >
A> > https://lists.freebsd.org/pipermail/freebsd-arch/2015-April/017154.html
A> 
A> I'm not sure that I understand what inconsistency you're referring to
A> here.  That the request page is handled differently from the non-request
A> pages?
A> 
A> Again, I'm happy with the changes to the handling of the request page. 
A> However, I'm still on the fence about the other proposed changes, and I
A> feel like the change to vm_thread_swapin() in the patch we are
A> discussing is qualitatively different from the other changes in that
A> same patch.  In particular, it is the only part of that patch that
A> touches non-request pages.  As such, I didn't think it belongs.

The vm_thread_swapin() is different from other consumers of
vm_pager_get_pages() since it is interested in non-request pages as much
as it is interested in the request page. The vm_thread_swapin() is rewritten
to utilize the new KPI. Before rewrite, it could request for pages, that
couldn't be read. The older KPI allowed that, since succeeding only with the
reqpage meant success. The new KPI would fail on such request. Now, if we
want to do multiple page request to vm_pager_get_pages(), we first need to
determine how many pages can we ask for via vm_pager_has_page().

-- 
Totus tuus, Glebius.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150615113100.GW73119>