Re: [RFC] Tracking mlocked pages and moving them off the LRU

["Nate Diller" <nate.diller@gmail.com>]

On 2/7/07, Christoph Lameter <clameter@sgi.com> wrote:
> On Tue, 6 Feb 2007, Nate Diller wrote:
>
> > > The dirty ratio with the ZVCS would be
> > >
> > > NR_DIRTY + NR_UNSTABLE_NFS
> > >         /
> > > NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE + NR_MLOCK
> >
> > I don't understand why you want to account mlocked pages in
> > dirty_ratio.  of course mlocked pages *can* be dirty, but they have no
> > relevance in the write throttling code.  the point of dirty ratio is
>
> mlocked pages can be counted as dirty pages. So if we do not include
> NR_MLOCK in the number of total pages that could be dirty then we may in
> some cases have >100% dirty pages.

unless we exclude mlocked dirty pages from NR_DIRTY accounting, which
is what i suggest should be done as part of this patch

> > to guarantee that there are some number of non-dirty, non-pinned,
> > non-mlocked pages on the LRU, to (try to) avoid deadlocks where the
> > writeback path needs to allocate pages, which many filesystems like to
> > do.  if an mlocked page is clean, there's still no way to free it up,
> > so it should not be treated as being on the LRU at all, for write
> > throttling.  the ideal (IMO) dirty ratio would be
>
> Hmmm... I think write throttling is different from reclaim. In write
> throttling the major objective is to decouple the applications from
> the physical I/O. So the dirty ratio specifies how much "buffer" space
> can be used for I/O. There is an issue that too many dirty pages will
> cause difficulty for reclaim because pages can only be reclaimed after
> writeback is complete.

NR_DIRTY is only used for write throttling, right?  well, and
reporting to user-space, but again, i suggest that user space should
get to see NR_MLOCKED as well.  would people flip out if NR_DIRTY
stopped showing pages that are mlocked, as long as a seperate
NR_MLOCKED variable was present?

> And yes this is not true for mlocked pages.
>
> >
> > NR_DIRTY - NR_DIRTY_MLOCKED + NR_UNSTABLE_NFS
> >        /
> > NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE
> >
> > obviously it's kinda useless to keep an NR_DIRTY_MLOCKED counter, any
> > of these mlock accounting schemes could easily be modified to update
> > the NR_DIRTY counter so that it only reflects dirty unpinned pages,
> > and not mlocked ones.
>
> So you would be okay with dirty_ratio possibly be >100% of mlocked pages
> are dirty?
>
> > is that the only place you wanted to have an accurate mocked page count?
>
> Rik had some other ideas on what to do with it. I also think we may end up
> checking for excessive high mlock counts in various tight VM situations.

i'd be wary of a VM algorithm that treated mlocked pages any
differently than, say, unreclaimable slab pages.  but there are no
concrete suggestions yet, so i won't comment further.

all this is not to say that i dislike the idea of keeping mlocked
pages off the LRU, quite the opposite i've been looking for this for a
while and was hoping that Stone Wang's wired list patch
(http://lkml.org/lkml/2006/3/20/128) would get further than it did.
but i don't see the need to keep strict accounting if it hurts
performance in the common case.

NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/