Can someone explain under what condition inode cache pages can be swapped out?

Can someone explain under what condition inode cache pages can be swapped out?

[Xin Zhao]

Specifically, how a swaping system determine which page should be
swapped out when memory is tight? Intuitively, I think inode cache
pages should be swapped out as late as possible. But how Linux mkae
decision on this? Why linux does not pin inode pages in the memory?

Thanks in advance for kind help!

xin

Re: Can someone explain under what condition inode cache pages can be swapped out?

[Jan Engelhardt]

>
> Specifically, how a swaping system determine which page should be
> swapped out when memory is tight?

LRU, f.ex.

> Intuitively, I think inode cache
> pages should be swapped out as late as possible.

I believe they are not swapped at all - they are shrunk when memory becomes 
a premium. (If this was a math class I'd say the cache size will be zero, 
although that's not too realistic in practice)

> But how Linux mkae
> decision on this? Why linux does not pin inode pages in the memory?

Ugh hell no. Then you could trigger OOM by simply walking a big filesystem. 


Jan Engelhardt
-- 

Re: Can someone explain under what condition inode cache pages can be swapped out?

[Xin Zhao]

Many thanks for kind replies.

You said inode cache is never swapped at all. In other words, the
inode cache pages are not swappable. How do you know the pages are
never swapped out? How can I tell whether a specific memory page is
swappable?  Can you point me to the right place in the kernel so that
I can see more details?

If my understanding is right, inode cache shrinker only frees the
reclaimable inodes, which means, if a lot of files are opened when
shrinker is activated, the shrinker may not find sufficient
reclaimable inodes to free enough space. What will Linux do under such
condition?

Xin

On 8/3/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
>
> >
> > Specifically, how a swaping system determine which page should be
> > swapped out when memory is tight?
>
> LRU, f.ex.
>
> > Intuitively, I think inode cache
> > pages should be swapped out as late as possible.
>
> I believe they are not swapped at all - they are shrunk when memory becomes
> a premium. (If this was a math class I'd say the cache size will be zero,
> although that's not too realistic in practice)
>
> > But how Linux mkae
> > decision on this? Why linux does not pin inode pages in the memory?
>
> Ugh hell no. Then you could trigger OOM by simply walking a big filesystem.
>
>
> Jan Engelhardt
> --
>

Re: Can someone explain under what condition inode cache pages can be swapped out?

[Jan Engelhardt]

>
> Many thanks for kind replies.
>
> You said inode cache is never swapped at all.

Yes.

> How do you know the pages are never swapped out?

Because
- they are in kernel memory
- if someone needs memory, we free some cache

> How can I tell whether a specific memory page is
> swappable?

Kernel memory is in general not swappable.

> If my understanding is right, inode cache shrinker only frees the
> reclaimable inodes, which means, if a lot of files are opened when
> shrinker is activated, the shrinker may not find sufficient
> reclaimable inodes to free enough space. What will Linux do under such
> condition?

Userspace will start to be swapped out to make room for kernel memory.
And if the swap is full, the OOM killer comes into action and will kill 
programs.
That's why it is so important to make sure that there are no memory leaks 
in kernelspace.


Jan Engelhardt
-- 

Re: Can someone explain under what condition inode cache pages can be swapped out?

[Al Boldi]

Jan Engelhardt wrote:
> > If my understanding is right, inode cache shrinker only frees the
> > reclaimable inodes, which means, if a lot of files are opened when
> > shrinker is activated, the shrinker may not find sufficient
> > reclaimable inodes to free enough space. What will Linux do under such
> > condition?
>
> Userspace will start to be swapped out to make room for kernel memory.
> And if the swap is full, the OOM killer comes into action and will kill
> programs.

The OOM-killing spree starts way before swap is full :(
see "swapping and oom-killer: gfp_mask=0x201d2, order=0" thread.


Thanks!

--
Al