[PATCH] prevent to reclaim anon page of lumpy reclaim for no swap space

[PATCH] prevent to reclaim anon page of lumpy reclaim for no swap space

[Minchan Kim]

This patch prevent to reclaim anon page in case of no swap space.
VM already prevent to reclaim anon page in various place.
But it doesnt't prevent it for lumpy reclaim.

It shuffles lru list unnecessary so that it is pointless.
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
---
 mm/vmscan.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 026f452..fb401fe 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -830,7 +830,13 @@ int __isolate_lru_page(struct page *page, int mode, int file)
 	 * When this function is being called for lumpy reclaim, we
 	 * initially look into all LRU pages, active, inactive and
 	 * unevictable; only give shrink_page_list evictable pages.
+
+	 * If we don't have enough swap space, reclaiming of anon page
+	 * is pointless.
 	 */
+	if (nr_swap_pages <= 0 && PageAnon(page))
+		return ret;
+
 	if (PageUnevictable(page))
 		return ret;
 
-- 
1.5.4.3




-- 
Kinds Regards
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] prevent to reclaim anon page of lumpy reclaim for no swap space

[Rik van Riel]

Minchan Kim wrote:
> This patch prevent to reclaim anon page in case of no swap space.
> VM already prevent to reclaim anon page in various place.
> But it doesnt't prevent it for lumpy reclaim.
> 
> It shuffles lru list unnecessary so that it is pointless.
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> ---
>  mm/vmscan.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 026f452..fb401fe 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -830,7 +830,13 @@ int __isolate_lru_page(struct page *page, int mode, int file)
>  	 * When this function is being called for lumpy reclaim, we
>  	 * initially look into all LRU pages, active, inactive and
>  	 * unevictable; only give shrink_page_list evictable pages.
> +
> +	 * If we don't have enough swap space, reclaiming of anon page
> +	 * is pointless.
>  	 */
> +	if (nr_swap_pages <= 0 && PageAnon(page))
> +		return ret;
> +

Should that be something like this:

	if (nr_swap_pages <= 0 && (PageAnon(page) && !PageSwapCache(page)))

We can still reclaim anonymous pages that already have
a swap slot assigned to them.

-- 
All rights reversed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] prevent to reclaim anon page of lumpy reclaim for no swap space

[Minchan Kim]

On Thu, Juna 25, 2009 at 11:09 PM, Rik van Riel<riel@redhat.com> wrote:
> Minchan Kim wrote:
>>
>> This patch prevent to reclaim anon page in case of no swap space.
>> VM already prevent to reclaim anon page in various place.
>> But it doesnt't prevent it for lumpy reclaim.
>>
>> It shuffles lru list unnecessary so that it is pointless.
>> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
>> ---
>>  mm/vmscan.c |    6 ++++++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 026f452..fb401fe 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -830,7 +830,13 @@ int __isolate_lru_page(struct page *page, int mode,
>> int file)
>>         * When this function is being called for lumpy reclaim, we
>>         * initially look into all LRU pages, active, inactive and
>>         * unevictable; only give shrink_page_list evictable pages.
>> +
>> +        * If we don't have enough swap space, reclaiming of anon page
>> +        * is pointless.
>>         */
>> +       if (nr_swap_pages <= 0 && PageAnon(page))
>> +               return ret;
>> +
>
> Should that be something like this:
>
>        if (nr_swap_pages <= 0 && (PageAnon(page) && !PageSwapCache(page)))
>
> We can still reclaim anonymous pages that already have
> a swap slot assigned to them.

Yes. I missed that.
Thanks for careful review. Rik. :)

>
> --
> All rights reversed.
>



-- 
Kinds regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] prevent to reclaim anon page of lumpy reclaim for no swap space

[KOSAKI Motohiro]

> This patch prevent to reclaim anon page in case of no swap space.
> VM already prevent to reclaim anon page in various place.
> But it doesnt't prevent it for lumpy reclaim.
>
> It shuffles lru list unnecessary so that it is pointless.

NAK.

1. if system have no swap, add_to_swap() never get swap entry.
   eary check don't improve performance so much.
2. __isolate_lru_page() is not only called lumpy reclaim case, but
also be called
    normal reclaim.
3. if system have no swap, anon pages shuffuling doesn't cause any matter.

Then, I don't think this patch's benefit is bigger than side effect.



> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> ---
>  mm/vmscan.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 026f452..fb401fe 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -830,7 +830,13 @@ int __isolate_lru_page(struct page *page, int mode, int file)
>         * When this function is being called for lumpy reclaim, we
>         * initially look into all LRU pages, active, inactive and
>         * unevictable; only give shrink_page_list evictable pages.
> +
> +        * If we don't have enough swap space, reclaiming of anon page
> +        * is pointless.
>         */
> +       if (nr_swap_pages <= 0 && PageAnon(page))
> +               return ret;
> +
>        if (PageUnevictable(page))
>                return ret;
>
> --
> 1.5.4.3
>
>
>
>
> --
> Kinds Regards
> Minchan Kim
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] prevent to reclaim anon page of lumpy reclaim for no swap space

[Minchan Kim]

On Thu, Jun 25, 2009 at 11:14 PM, KOSAKI
Motohiro<kosaki.motohiro@jp.fujitsu.com> wrote:
>> This patch prevent to reclaim anon page in case of no swap space.
>> VM already prevent to reclaim anon page in various place.
>> But it doesnt't prevent it for lumpy reclaim.
>>
>> It shuffles lru list unnecessary so that it is pointless.
>
> NAK.
>
> 1. if system have no swap, add_to_swap() never get swap entry.
>   eary check don't improve performance so much.

Hmm. I mean no swap space but not no swap device.
add_to_swap ? You mean Rik pointed me out ?
If system have swap device, Rik's pointing is right.
I will update his suggestion.

> 2. __isolate_lru_page() is not only called lumpy reclaim case, but
> also be called
>    normal reclaim.

You mean about performance degradation ?
I think most case have enough swap space and then one condition
variable(nr_swap_page) check is trivial. I think.
We can also use [un]likely but I am not sure it help us.


> 3. if system have no swap, anon pages shuffuling doesn't cause any matter.

Again, I mean no swap space but no swap device system.
And I have a plan to remove anon_vma in no swap device system.

As you point me out, it's pointless in no swap device system.
I don't like unnecessary structure memory footprint and locking overhead.
I think no swap device system is problem in server environment as well
as embedded. but I am not sure when I will do. :)


> Then, I don't think this patch's benefit is bigger than side effect.
>
>
>
>> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
>> ---
>>  mm/vmscan.c |    6 ++++++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 026f452..fb401fe 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -830,7 +830,13 @@ int __isolate_lru_page(struct page *page, int mode, int file)
>>         * When this function is being called for lumpy reclaim, we
>>         * initially look into all LRU pages, active, inactive and
>>         * unevictable; only give shrink_page_list evictable pages.
>> +
>> +        * If we don't have enough swap space, reclaiming of anon page
>> +        * is pointless.
>>         */
>> +       if (nr_swap_pages <= 0 && PageAnon(page))
>> +               return ret;
>> +
>>        if (PageUnevictable(page))
>>                return ret;
>>
>> --
>> 1.5.4.3
>>
>>
>>
>>
>> --
>> Kinds Regards
>> Minchan Kim
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>>
>



--
Kinds regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] prevent to reclaim anon page of lumpy reclaim for no swap space

[Lee Schermerhorn]

On Thu, 2009-06-25 at 23:44 +0900, Minchan Kim wrote:
> On Thu, Jun 25, 2009 at 11:14 PM, KOSAKI
> Motohiro<kosaki.motohiro@jp.fujitsu.com> wrote:
> >> This patch prevent to reclaim anon page in case of no swap space.
> >> VM already prevent to reclaim anon page in various place.
> >> But it doesnt't prevent it for lumpy reclaim.
> >>
> >> It shuffles lru list unnecessary so that it is pointless.
> >
> > NAK.
> >
> > 1. if system have no swap, add_to_swap() never get swap entry.
> >   eary check don't improve performance so much.
> 
> Hmm. I mean no swap space but not no swap device.
> add_to_swap ? You mean Rik pointed me out ?
> If system have swap device, Rik's pointing is right.
> I will update his suggestion.
> 
> > 2. __isolate_lru_page() is not only called lumpy reclaim case, but
> > also be called
> >    normal reclaim.
> 
> You mean about performance degradation ?
> I think most case have enough swap space and then one condition
> variable(nr_swap_page) check is trivial. I think.
> We can also use [un]likely but I am not sure it help us.
> 
> 
> > 3. if system have no swap, anon pages shuffuling doesn't cause any matter.
> 
> Again, I mean no swap space but no swap device system.
> And I have a plan to remove anon_vma in no swap device system.
> 
> As you point me out, it's pointless in no swap device system.
> I don't like unnecessary structure memory footprint and locking overhead.
> I think no swap device system is problem in server environment as well
> as embedded. but I am not sure when I will do. :)
> 

How will we walk the reverse map for try_to_unmap() for page migration
or try_to_munlock() w/o anon_vma?  Perhaps one can remove anon_vma when
there is no swap device and migration and the unevictable lru are not
configured--e.g., for embedded systems.

Lee

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] prevent to reclaim anon page of lumpy reclaim for no swap space

[Minchan Kim]

Hi, Lee.

On Thu, Jun 25, 2009 at 11:54 PM, Lee
Schermerhorn<Lee.Schermerhorn@hp.com> wrote:
> On Thu, 2009-06-25 at 23:44 +0900, Minchan Kim wrote:
>> On Thu, Jun 25, 2009 at 11:14 PM, KOSAKI
>> Motohiro<kosaki.motohiro@jp.fujitsu.com> wrote:
>> >> This patch prevent to reclaim anon page in case of no swap space.
>> >> VM already prevent to reclaim anon page in various place.
>> >> But it doesnt't prevent it for lumpy reclaim.
>> >>
>> >> It shuffles lru list unnecessary so that it is pointless.
>> >
>> > NAK.
>> >
>> > 1. if system have no swap, add_to_swap() never get swap entry.
>> >   eary check don't improve performance so much.
>>
>> Hmm. I mean no swap space but not no swap device.
>> add_to_swap ? You mean Rik pointed me out ?
>> If system have swap device, Rik's pointing is right.
>> I will update his suggestion.
>>
>> > 2. __isolate_lru_page() is not only called lumpy reclaim case, but
>> > also be called
>> >    normal reclaim.
>>
>> You mean about performance degradation ?
>> I think most case have enough swap space and then one condition
>> variable(nr_swap_page) check is trivial. I think.
>> We can also use [un]likely but I am not sure it help us.
>>
>>
>> > 3. if system have no swap, anon pages shuffuling doesn't cause any matter.
>>
>> Again, I mean no swap space but no swap device system.
>> And I have a plan to remove anon_vma in no swap device system.
>>
>> As you point me out, it's pointless in no swap device system.
>> I don't like unnecessary structure memory footprint and locking overhead.
>> I think no swap device system is problem in server environment as well
>> as embedded. but I am not sure when I will do. :)
>>
>
> How will we walk the reverse map for try_to_unmap() for page migration
> or try_to_munlock() w/o anon_vma?  Perhaps one can remove anon_vma when
> there is no swap device and migration and the unevictable lru are not
> configured--e.g., for embedded systems.

You're right. In addition, there are HWPoison and maybe KSM.
Also, unevictable lru list isn't option any more even embedded system.

Actually I considered it in embedded system as you said.
I think above enumerated cases are not needed in embedded system.
Memory footprint and unnecessary locking is more important in embedded
since small memory and realtime.

Anyway, I think it's not easy so now it's just plan.
Welcome to any comment to prevent my vain effort. :)

Thanks for valuable comment. Lee. :)

> Lee
>
>



-- 
Kinds regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>