Date: Sun, 25 Jul 2010 17:19:41 +0300 From: Andriy Gapon <avg@freebsd.org> To: RW <rwmaillists@googlemail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: pageout question Message-ID: <4C4C47FD.6080802@freebsd.org> In-Reply-To: <20100725144141.6f1f33cc@gumby.homeunix.com> References: <4C4B4BAB.3000005@freebsd.org> <20100725003144.3cfead39@gumby.homeunix.com> <4C4C0CD9.6000002@freebsd.org> <20100725144141.6f1f33cc@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 25/07/2010 16:41 RW said the following: > On Sun, 25 Jul 2010 13:07:21 +0300 > Andriy Gapon <avg@freebsd.org> wrote: > >> on 25/07/2010 02:31 RW said the following: > >>> As I understand it the hysteresis is done inside vm_pageout_scan, >>> and the expectation is that one pass will typically satisfy this >>> because the design aims to keep enough clean pages in the inactive >>> queue. > >> But I am not sure about "clean pages in the inactive queue" ... But I >> do not see any code ensuring level of _clean_ inactive pages. > > In FreeBSD the inactive queue contains disk cache pages which normally > provide most of the clean pages needed. In addition pages are dribbled > out to swap, and the resulting clean pages are placed at the back of > the inactive queue to make another pass. Well, "normally" and "most" are not quite quantitative. Personally, I do not see any guarantees that inactive queue would contain enough clean pages to reach paging target on a single pass. >>> I'm not sure if the vm_paging_needed() call is correct or not, but >>> it may be that that the intent is to avoid immediately going back >>> to a depleted inactive queue when cache+free is within normal >>> bounds, because it could result in avoidable paging to swap. >> Well, OTOH, if the current pass results in many pages being >> re-activated and many pages still left on the inactive queue because >> they are dirty (see maxlaunder in vm_pageout_scan), > > Dirty-pages make three passes through the inactive queue: twice dirty, > once clean. They are paged-out at the end of the second paass, so it's > unlike that they reactivated except under very heavy thrashing. I didn't mean to say that dirty pages would get re-activated. Clean pages can perfectly be re-activated if they were referenced since their de-activation time. >> then it is >> premature to quit paging when we only reached bare minimum of >> available pages (see pass and maxlaunder again). IMHO, of course. > > It's not the bare minimum, that's another level that vm_page_count_min() > tests for. I meant bare minimum to stop paging, that is, going above lower watermark of the paging hysteresis. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C4C47FD.6080802>