2.4.10 VM: what avoids from having lots of unwriteable inactive pages

2.4.10 VM: what avoids from having lots of unwriteable inactive pages

[Marcelo Tosatti]

Linus,

What avoids us from having a lot of unfreeable (eg mapped by ptes) pages
on the inactive list ? 

Since we don't move those pages to the active list at shrink_cache(), I
see that we rely on swap_out() to deactivate pte's and make pages on the
inactive list freeable.

Is that right ? 

Re: 2.4.10 VM: what avoids from having lots of unwriteable inactive pages

[Marcelo Tosatti]

On Mon, 24 Sep 2001, Linus Torvalds wrote:

> 
> On Mon, 24 Sep 2001, Marcelo Tosatti wrote:
> >
> > What avoids us from having a lot of unfreeable (eg mapped by ptes) pages
> > on the inactive list ?
> 
> Nothing.
> 
> If we can't shrink them, we'll fall out and do vmscanning.
> 
> Which is exactly what we want to do - it automatically acts as a "uhhuh,
> we've got to do something now" thing.

Think about a case where the inactive list if _full_ of mapped pages.
(which can easily happen, because one fault (do_swap_page) will _not_ move
the page to the active list directly --- it has to be accessed (Referenced
bit) twice (mark_page_accessed)).

We _think_ we don't have a shortage, so we won't call refill_inactive().

We keep calling swap_out(), which will not deactivate pages which _can_ be
written out, until we deactivate the pte's from the pages which are on the
inactive list.

Nothing prevents that, right ? 

Re: 2.4.10 VM: what avoids from having lots of unwriteable inactive pages

[Linus Torvalds]

On Mon, 24 Sep 2001, Marcelo Tosatti wrote:
>
> What avoids us from having a lot of unfreeable (eg mapped by ptes) pages
> on the inactive list ?

Nothing.

If we can't shrink them, we'll fall out and do vmscanning.

Which is exactly what we want to do - it automatically acts as a "uhhuh,
we've got to do something now" thing.

The tuning may be way off, of course. If we scan too many pages, we won't
fall out early enough..

		Linus

Re: 2.4.10 VM: what avoids from having lots of unwriteable inactive pages

[Linus Torvalds]

On Mon, 24 Sep 2001, Marcelo Tosatti wrote:
>
> We keep calling swap_out(), which will not deactivate pages which _can_ be
> written out, until we deactivate the pte's from the pages which are on the
> inactive list.

swap_out() will deactivate everything it finds to be not-recently used,
and that's how the inactive list ends up getting replenished.

But if you want to put an unconditional "refill_inactive()" after the
inactive shrink failed, just to work with the case of the active list
having a lot of interesting pages. That's not a mapped vs unmapped issue,
that's more a "maybe all the DMA pages are on the active list" kind of
thing.

		Linus

Re: 2.4.10 VM: what avoids from having lots of unwriteable inactive pages

[Rik van Riel]

On Mon, 24 Sep 2001, Linus Torvalds wrote:
> On Mon, 24 Sep 2001, Marcelo Tosatti wrote:
> >
> > We keep calling swap_out(), which will not deactivate pages which _can_ be
> > written out, until we deactivate the pte's from the pages which are on the
> > inactive list.
>
> swap_out() will deactivate everything it finds to be not-recently used,
> and that's how the inactive list ends up getting replenished.

mlock()

Rik
--
IA64: a worthy successor to the i860.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: 2.4.10 VM: what avoids from having lots of unwriteable inactive pages

[Linus Torvalds]

On Tue, 25 Sep 2001, Rik van Riel wrote:
> >
> > swap_out() will deactivate everything it finds to be not-recently used,
> > and that's how the inactive list ends up getting replenished.
>
> mlock()

Hey, if you've mlock'ed more than your available memory, there's nothing
the VM layer can do. Except maybe a nice printk("Kiss your *ss goodbye");

		Linus

Re: 2.4.10 VM: what avoids from having lots of unwriteable inactive pages

[Rik van Riel]

On Tue, 25 Sep 2001, Linus Torvalds wrote:
> On Tue, 25 Sep 2001, Rik van Riel wrote:
> > >
> > > swap_out() will deactivate everything it finds to be not-recently used,
> > > and that's how the inactive list ends up getting replenished.
> >
> > mlock()
>
> Hey, if you've mlock'ed more than your available memory, there's nothing
> the VM layer can do. Except maybe a nice printk("Kiss your *ss goodbye");

But if you've mlock()ed enough to clog up the inactive
list, the VM could just move the pages it cannot free
back to the active list and it will come across those
pages which are freeable eventually.

Note that the maximum amount of mlock()ed memory is way
higher than the maximum amount of pages the system puts
on the inactive list.

(at least, it was last I looked at the maximum number
of mlocked pages)

regards,

Rik
--
IA64: a worthy successor to the i860.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: 2.4.10 VM: what avoids from having lots of unwriteable inactive pages

[Marcelo Tosatti]

On Tue, 25 Sep 2001, Rick Haines wrote:

> On Tue, Sep 25, 2001 at 01:13:37PM -0300, Rik van Riel wrote:
> > On Tue, 25 Sep 2001, Linus Torvalds wrote:
> > > On Tue, 25 Sep 2001, Rik van Riel wrote:
> > > > >
> > > > > swap_out() will deactivate everything it finds to be not-recently used,
> > > > > and that's how the inactive list ends up getting replenished.
> > > >
> > > > mlock()
> > >
> > > Hey, if you've mlock'ed more than your available memory, there's nothing
> > > the VM layer can do. Except maybe a nice printk("Kiss your *ss goodbye");
> 
> Shouldn't there be a threshold where mlock will fail?

There is (for users). Take a look at ulimit:

 -l     The maximum size that may be locked into memory



> Or are you saying that in general mlocking lots of memory will screw the
> VM?

Yes it will.

Re: 2.4.10 VM: what avoids from having lots of unwriteable inactive pages

[Rick Haines]

On Tue, Sep 25, 2001 at 01:13:37PM -0300, Rik van Riel wrote:
> On Tue, 25 Sep 2001, Linus Torvalds wrote:
> > On Tue, 25 Sep 2001, Rik van Riel wrote:
> > > >
> > > > swap_out() will deactivate everything it finds to be not-recently used,
> > > > and that's how the inactive list ends up getting replenished.
> > >
> > > mlock()
> >
> > Hey, if you've mlock'ed more than your available memory, there's nothing
> > the VM layer can do. Except maybe a nice printk("Kiss your *ss goodbye");

Shouldn't there be a threshold where mlock will fail?
Or are you saying that in general mlocking lots of memory will screw the
VM?

> But if you've mlock()ed enough to clog up the inactive
> list, the VM could just move the pages it cannot free
> back to the active list and it will come across those
> pages which are freeable eventually.
> 
> Note that the maximum amount of mlock()ed memory is way
> higher than the maximum amount of pages the system puts
> on the inactive list.
> 
> (at least, it was last I looked at the maximum number
> of mlocked pages)
> 
> regards,
> 
> Rik
> --
> IA64: a worthy successor to the i860.
> 
> 		http://www.surriel.com/
> http://www.conectiva.com/	http://distro.conectiva.com/
> 
> -
> 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/

-- 
Rick (rick@kuroyi.net)
http://dxr3.sourceforge.net

I think the slogan of the fansubbers puts
it best: "Cheaper than crack, and lots more fun."