Sorry for late response.
On Fri, Jan 28, 2011 at 8:18 PM, Balbir Singh <[email protected]> wrote:
> * MinChan Kim <[email protected]> [2011-01-28 16:24:19]:
>
>> >
>> > But the assumption for LRU order to change happens only if the page
>> > cannot be successfully freed, which means it is in some way active..
>> > and needs to be moved no?
>>
>> 1. holded page by someone
>> 2. mapped pages
>> 3. active pages
>>
>> 1 is rare so it isn't the problem.
>> Of course, in case of 3, we have to activate it so no problem.
>> The problem is 2.
>>
>
> 2 is a problem, but due to the size aspects not a big one. Like you
> said even lumpy reclaim affects it. May be the reclaim code could
> honour may_unmap much earlier.
Even if it is, it's a trade-off to get a big contiguous memory. I
don't want to add new mess. (In addition, lumpy is weak by compaction
as time goes by)
What I have in mind for preventing LRU ignore is that put the page
into original position instead of head of lru. Maybe it can help the
situation both lumpy and your case. But it's another story.
How about the idea?
I borrow the idea from CFLRU[1]
- PCFLRU(Page-Cache First LRU)
When we allocates new page for page cache, we adds the page into LRU's tail.
When we map the page cache into page table, we rotate the page into LRU's head.
So, inactive list's result is following as.
M.P : mapped page
N.P : none-mapped page
HEAD-M.P-M.P-M.P-M.P-N.P-N.P-N.P-N.P-N.P-TAIL
Admin can set threshold window size which determines stop reclaiming
none-mapped page contiguously.
I think it needs some tweak of page cache/page mapping functions but
we can use kswapd/direct reclaim without change.
Also, it can change page reclaim policy totally but it's just what you
want, I think.
[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.100.6188&rep=rep1&type=pdf
>
> --
> Three Cheers,
> Balbir
>
--
Kind regards,
Minchan Kim
I don't know why the part of message is deleted only when I send you.
Maybe it's gmail bug.
I hope mail sending is successful in this turn. :)
On Thu, Feb 10, 2011 at 2:33 PM, Minchan Kim <[email protected]> wrote:
> Sorry for late response.
>
> On Fri, Jan 28, 2011 at 8:18 PM, Balbir Singh <[email protected]> wrote:
>> * MinChan Kim <[email protected]> [2011-01-28 16:24:19]:
>>
>>> >
>>> > But the assumption for LRU order to change happens only if the page
>>> > cannot be successfully freed, which means it is in some way active..
>>> > and needs to be moved no?
>>>
>>> 1. holded page by someone
>>> 2. mapped pages
>>> 3. active pages
>>>
>>> 1 is rare so it isn't the problem.
>>> Of course, in case of 3, we have to activate it so no problem.
>>> The problem is 2.
>>>
>>
>> 2 is a problem, but due to the size aspects not a big one. Like you
>> said even lumpy reclaim affects it. May be the reclaim code could
>> honour may_unmap much earlier.
>
> Even if it is, it's a trade-off to get a big contiguous memory. I
> don't want to add new mess. (In addition, lumpy is weak by compaction
> as time goes by)
> What I have in mind for preventing LRU ignore is that put the page
> into original position instead of head of lru. Maybe it can help the
> situation both lumpy and your case. But it's another story.
>
> How about the idea?
>
> I borrow the idea from CFLRU[1]
> - PCFLRU(Page-Cache First LRU)
>
> When we allocates new page for page cache, we adds the page into LRU's tail.
> When we map the page cache into page table, we rotate the page into LRU's head.
>
> So, inactive list's result is following as.
>
> M.P : mapped page
> N.P : none-mapped page
>
> HEAD-M.P-M.P-M.P-M.P-N.P-N.P-N.P-N.P-N.P-TAIL
>
> Admin can set threshold window size which determines stop reclaiming
> none-mapped page contiguously.
>
> I think it needs some tweak of page cache/page mapping functions but
> we can use kswapd/direct reclaim without change.
>
> Also, it can change page reclaim policy totally but it's just what you
> want, I think.
>
> [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.100.6188&rep=rep1&type=pdf
>
>>
>> --
>> Three Cheers,
>> Balbir
>>
>
>
>
> --
> Kind regards,
> Minchan Kim
>
--
Kind regards,
Minchan Kim
* MinChan Kim <[email protected]> [2011-02-10 14:41:44]:
> I don't know why the part of message is deleted only when I send you.
> Maybe it's gmail bug.
>
> I hope mail sending is successful in this turn. :)
>
> On Thu, Feb 10, 2011 at 2:33 PM, Minchan Kim <[email protected]> wrote:
> > Sorry for late response.
> >
> > On Fri, Jan 28, 2011 at 8:18 PM, Balbir Singh <[email protected]> wrote:
> >> * MinChan Kim <[email protected]> [2011-01-28 16:24:19]:
> >>
> >>> >
> >>> > But the assumption for LRU order to change happens only if the page
> >>> > cannot be successfully freed, which means it is in some way active..
> >>> > and needs to be moved no?
> >>>
> >>> 1. holded page by someone
> >>> 2. mapped pages
> >>> 3. active pages
> >>>
> >>> 1 is rare so it isn't the problem.
> >>> Of course, in case of 3, we have to activate it so no problem.
> >>> The problem is 2.
> >>>
> >>
> >> 2 is a problem, but due to the size aspects not a big one. Like you
> >> said even lumpy reclaim affects it. May be the reclaim code could
> >> honour may_unmap much earlier.
> >
> > Even if it is, it's a trade-off to get a big contiguous memory. I
> > don't want to add new mess. (In addition, lumpy is weak by compaction
> > as time goes by)
> > What I have in mind for preventing LRU ignore is that put the page
> > into original position instead of head of lru. Maybe it can help the
> > situation both lumpy and your case. But it's another story.
> >
> > How about the idea?
> >
> > I borrow the idea from CFLRU[1]
> > - PCFLRU(Page-Cache First LRU)
> >
> > When we allocates new page for page cache, we adds the page into LRU's tail.
> > When we map the page cache into page table, we rotate the page into LRU's head.
> >
> > So, inactive list's result is following as.
> >
> > M.P : mapped page
> > N.P : none-mapped page
> >
> > HEAD-M.P-M.P-M.P-M.P-N.P-N.P-N.P-N.P-N.P-TAIL
> >
> > Admin can set threshold window size which determines stop reclaiming
> > none-mapped page contiguously.
> >
> > I think it needs some tweak of page cache/page mapping functions but
> > we can use kswapd/direct reclaim without change.
> >
> > Also, it can change page reclaim policy totally but it's just what you
> > want, I think.
> >
I am not sure how this would work, moreover the idea behind
min_unmapped_pages is to keep sufficient unmapped pages around for the
FS metadata and has been working with the existing code for zone
reclaim. What you propose is more drastic re-org of the LRU and I am
not sure I have the apetite for it.
--
Three Cheers,
Balbir
On Mon, Feb 14, 2011 at 2:33 AM, Balbir Singh <[email protected]> wrote:
> * MinChan Kim <[email protected]> [2011-02-10 14:41:44]:
>
>> I don't know why the part of message is deleted only when I send you.
>> Maybe it's gmail bug.
>>
>> I hope mail sending is successful in this turn. :)
>>
>> On Thu, Feb 10, 2011 at 2:33 PM, Minchan Kim <[email protected]> wrote:
>> > Sorry for late response.
>> >
>> > On Fri, Jan 28, 2011 at 8:18 PM, Balbir Singh <[email protected]> wrote:
>> >> * MinChan Kim <[email protected]> [2011-01-28 16:24:19]:
>> >>
>> >>> >
>> >>> > But the assumption for LRU order to change happens only if the page
>> >>> > cannot be successfully freed, which means it is in some way active..
>> >>> > and needs to be moved no?
>> >>>
>> >>> 1. holded page by someone
>> >>> 2. mapped pages
>> >>> 3. active pages
>> >>>
>> >>> 1 is rare so it isn't the problem.
>> >>> Of course, in case of 3, we have to activate it so no problem.
>> >>> The problem is 2.
>> >>>
>> >>
>> >> 2 is a problem, but due to the size aspects not a big one. Like you
>> >> said even lumpy reclaim affects it. May be the reclaim code could
>> >> honour may_unmap much earlier.
>> >
>> > Even if it is, it's a trade-off to get a big contiguous memory. I
>> > don't want to add new mess. (In addition, lumpy is weak by compaction
>> > as time goes by)
>> > What I have in mind for preventing LRU ignore is that put the page
>> > into original position instead of head of lru. Maybe it can help the
>> > situation both lumpy and your case. But it's another story.
>> >
>> > How about the idea?
>> >
>> > I borrow the idea from CFLRU[1]
>> > - PCFLRU(Page-Cache First LRU)
>> >
>> > When we allocates new page for page cache, we adds the page into LRU's tail.
>> > When we map the page cache into page table, we rotate the page into LRU's head.
>> >
>> > So, inactive list's result is following as.
>> >
>> > M.P : mapped page
>> > N.P : none-mapped page
>> >
>> > HEAD-M.P-M.P-M.P-M.P-N.P-N.P-N.P-N.P-N.P-TAIL
>> >
>> > Admin can set threshold window size which determines stop reclaiming
>> > none-mapped page contiguously.
>> >
>> > I think it needs some tweak of page cache/page mapping functions but
>> > we can use kswapd/direct reclaim without change.
>> >
>> > Also, it can change page reclaim policy totally but it's just what you
>> > want, I think.
>> >
>
> I am not sure how this would work, moreover the idea behind
> min_unmapped_pages is to keep sufficient unmapped pages around for the
> FS metadata and has been working with the existing code for zone
> reclaim. What you propose is more drastic re-org of the LRU and I am
> not sure I have the apetite for it.
Yes. My suggestion can change LRU order totally but it can't meet your
goal so it was a bad idea. Sorry for bothering you.
I can add reviewed-by [1/3],[2/3], but still doubt [3/3].
LRU ordering problem as I mentioned is not only your problem but it's
general problem these day(ex, more aggressive compaction/lumpy
reclaim). So we may need general solution if it is real problem.
Okay. I don't oppose your approach from now on until I can prove how
much LRU-reordering makes bad effect. (But still I raise my eyebrow
on implementation [3/3] but I don't oppose it until I suggest better
approach)
Thanks.
--
Kind regards,
Minchan Kim