Control page reclaim granularity

Hi list,

Recently we encounter a problem about page reclaim. I abstract it in here. The problem is that there are two different file types. One is small index file, and another is large data file. The index file is mmaped into memory, and application hope that they can be kept in memory and don't be reclaimed too frequently. The data file is manipulted by read/write, and they should be reclaimed more frequently than the index file.

As previously discussion [1], Konstantin suggest me to mmap index file with PROT_EXEC flag. Meanwhile he provides a patch to set a flag in mm_flags to increase the priority of mmaped file pages. However, these solutions are not perfect. I review the related patches (8cab4754 and c909e993) and I think that mmaped index file with PROT_EXEC flag is too tricky. From the view of applicaton programmer, index file is a regular file that stores some data. So they should be mmap with PROT_READ | PROT_WRITE rather than with PROT_EXEC. As commit log said (8cab4754), the purpose of this patch is to keep executable code in memory to improve the response of application. In addition, Kongstantin's patch needs to adjust the application program. So in some cases, we cannot touch the code of application, and this patch is useless.

I have discussed with Kongstantin about this problem and we think maybe kernel should provide some mechanism. For example, user can set memory pressure priorities for vma or inode, or mmaped pages and file pages can be reclaimed separately. If someone has thought about it, please let me know. Any feedbacks are welcomed. Thank you.

Previously discussion:
1. http://marc.info/?l=linux-mm&m=132947026019538&w=2

Regards,
Zheng

Hi Greg,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel mailing list. So please Cc me.

I am glad to receive your reply and I am very interesting for your approach. Actually I am not very familiar with CGroup. So would you please send your patch to me if you can? Thank you all the same.

Regards,
Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Greg,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel mailing list. So please Cc me.

I am glad to receive your reply and I am very interesting for your approach. Actually I am not very familiar with CGroup. So would you please send your patch to me if you can? Thank you all the same.

Regards,
Zheng

Hi list,

Recently we encounter a problem about page reclaim. I abstract it in here. The problem is that there are two different file types. One is small index file, and another is large data file. The index file is mmaped into memory, and application hope that they can be kept in memory and don't be reclaimed too frequently. The data file is manipulted by read/write, and they should be reclaimed more frequently than the index file.

As previously discussion [1], Konstantin suggest me to mmap index file with PROT_EXEC flag. Meanwhile he provides a patch to set a flag in mm_flags to increase the priority of mmaped file pages. However, these solutions are not perfect. I review the related patches (8cab4754 and c909e993) and I think that mmaped index file with PROT_EXEC flag is too tricky. From the view of applicaton programmer, index file is a regular file that stores some data. So they should be mmap with PROT_READ | PROT_WRITE rather than with PROT_EXEC. As commit log said (8cab4754), the purpose of this patch is to keep executable code in memory to improve the response of application. In addition, Kongstantin's patch needs to adjust the application program. So in some cases, we cannot touch the code of application, and this patch is useless.

I have discussed with Kongstantin about this problem and we think maybe kernel should provide some mechanism. For example, user can set memory pressure priorities for vma or inode, or mmaped pages and file pages can be reclaimed separately. If someone has thought about it, please let me know. Any feedbacks are welcomed. Thank you.

Previously discussion:
1. http://marc.info/?l=linux-mm&m=132947026019538&w=2

Regards,
Zheng

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel mailing list. So please Cc me.

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the second case, the application wants to keep mmaped page into memory and let file pages to be reclaimed firstly. So, IMO, when application uses mmap(2) to manipulate files, it is possible to imply that it wants keep these mmaped pages into memory and do not be reclaimed. At least these pages do not be reclaimed early than file pages. I think that maybe we can recover that routine and provide a sysctl parameter to let the user to set this ratio between mmaped pages and file pages.

Regards,
Zheng

I forgot to Ccing you.
Sorry.

---------- Forwarded message ----------
From: Minchan Kim <[email protected]>
Date: Mon, Mar 12, 2012 at 9:28 AM
Subject: Re: Control page reclaim granularity
To: Minchan Kim <[email protected]>, linux-mm <[email protected]>, linux-kernel <[email protected]>, Konstantin Khlebnikov < [email protected]>, [email protected], [email protected]

Quoted 5 lines · Zheng Liu

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel mailing list. So please Cc me.

Quoted 12 lines

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the second case, the application wants to keep mmaped page into memory and let file pages to be reclaimed firstly. So, IMO, when application uses mmap(2) to manipulate files, it is possible to imply that it wants keep these mmaped pages into memory and do not be reclaimed. At least these pages do not be reclaimed early than file pages. I think that maybe we can recover that routine and provide a sysctl parameter to let the user to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially. Sometimem, someone may use mmap by reducing buffer copy compared to read system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly. I think we can implement it by madvise and fadvise's WILLNEED option. Current implementation is just readahead if there isn't a page in memory but I think
we can promote from inactive to active if there is already a page in memory.

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

Quoted 43 lines · Minchan Kim

I forgot to Ccing you.
Sorry.

---------- Forwarded message ----------
From: Minchan Kim <[email protected]>
Date: Mon, Mar 12, 2012 at 9:28 AM
Subject: Re: Control page reclaim granularity
To: Minchan Kim <[email protected]>, linux-mm <[email protected]>, linux-kernel <[email protected]>, Konstantin Khlebnikov < [email protected]>, [email protected], [email protected]

Quoted 5 lines · Zheng Liu

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel mailing list. So please Cc me.

Quoted 12 lines

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the second case, the application wants to keep mmaped page into memory and let file pages to be reclaimed firstly. So, IMO, when application uses mmap(2) to manipulate files, it is possible to imply that it wants keep these mmaped pages into memory and do not be reclaimed. At least these pages do not be reclaimed early than file pages. I think that maybe we can recover that routine and provide a sysctl parameter to let the user to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially. Sometimem, someone may use mmap by reducing buffer copy compared to read system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly. I think we can implement it by madvise and fadvise's WILLNEED option. Current implementation is just readahead if there isn't a page in memory but I think
we can promote from inactive to active if there is already a page in memory.

Quoted 3 lines

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

Thank you for your advice. But I still have question about this solution. If we improve the madvise(2) and fadvise(2)'s WILLNEED option, it will cause an inconsistently status for pages that be manipulated by madvise(2) and/or fadvise(2). For example, when I call madvise with WILLNEED flag, some pages will be moved into active list if they already have been in memory, and other pages will be read into memory and be saved in inactive list if they don't be in memory. Then pages that are in inactive list are possible to be reclaim. So from the view of users, it is inconsistent because some pages are in memory and some pages are reclaimed. But actually the user hopes that all of pages can be kept in memory. IMHO, this inconsistency is weird and makes users puzzled.

Regards,
Zheng

Quoted 48 lines · Zheng Liu

Quoted 43 lines · Minchan Kim

I forgot to Ccing you.
Sorry.

---------- Forwarded message ----------
From: Minchan Kim<[email protected]>
Date: Mon, Mar 12, 2012 at 9:28 AM
Subject: Re: Control page reclaim granularity
To: Minchan Kim<[email protected]>, linux-mm<[email protected]>, linux-kernel<[email protected]>, Konstantin Khlebnikov< [email protected]>, [email protected], [email protected]

Quoted 5 lines · Zheng Liu

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel mailing list. So please Cc me.

Quoted 12 lines

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the second case, the application wants to keep mmaped page into memory and let file pages to be reclaimed firstly. So, IMO, when application uses mmap(2) to manipulate files, it is possible to imply that it wants keep these mmaped pages into memory and do not be reclaimed. At least these pages do not be reclaimed early than file pages. I think that maybe we can recover that routine and provide a sysctl parameter to let the user to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially. Sometimem, someone may use mmap by reducing buffer copy compared to read system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly. I think we can implement it by madvise and fadvise's WILLNEED option. Current implementation is just readahead if there isn't a page in memory but I think
we can promote from inactive to active if there is already a page in memory.

Quoted 3 lines

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

Quoted 12 lines

Thank you for your advice. But I still have question about this solution. If we improve the madvise(2) and fadvise(2)'s WILLNEED option, it will cause an inconsistently status for pages that be manipulated by madvise(2) and/or fadvise(2). For example, when I call madvise with WILLNEED flag, some pages will be moved into active list if they already have been in memory, and other pages will be read into memory and be saved in inactive list if they don't be in memory. Then pages that are in inactive list are possible to be reclaim. So from the view of users, it is inconsistent because some pages are in memory and some pages are reclaimed. But actually the user hopes that all of pages can be kept in memory. IMHO, this inconsistency is weird and makes users puzzled.

Now problem is that

1. User want to keep pages which are used once in a while in memory.
2. Kernel want to reclaim them because they are surely reclaim target pages in point of view by LRU.

The most desriable approach is that user should use mlock to guarantee them in memory. But mlock is too big overhead and user doesn't want to keep memory all pages all at once.(Ie, he want demand paging when he need the page) Right?

madvise, it's a just hint for kernel and kernel doesn't need to make sure madvise's behavior. In point of view, such inconsistency might not be a big problem.

Big problem I think now is that user should use madvise(WILLNEED) periodically because such activation happens once when user calls madvise. If user doesn't use page frequently after user calls it, it ends up moving into inactive list and even could be reclaimed. It's not good. :-(

Okay. How about adding new VM_WORKINGSET?
And reclaimer would give one more round trip in active/inactive list when reclaim happens if the page is referenced.

Sigh. We have no room for new VM_FLAG in 32 bit.

Quoted 103 lines · Minchan Kim

Quoted 58 lines · Zheng Liu

Quoted 53 lines · Minchan Kim

I forgot to Ccing you.
Sorry.

---------- Forwarded message ----------
From: Minchan Kim<[email protected]>
Date: Mon, Mar 12, 2012 at 9:28 AM
Subject: Re: Control page reclaim granularity
To: Minchan Kim<[email protected]>, linux-mm<[email protected]>, linux-kernel<[email protected]>, Konstantin Khlebnikov< [email protected]>, [email protected], [email protected]

Quoted 17 lines · Zheng Liu

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel
mailing list. So please Cc me.

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the
second case, the application wants to keep mmaped page into memory and
let file pages to be reclaimed firstly. So, IMO, when application uses
mmap(2) to manipulate files, it is possible to imply that it wants

Quoted 8 lines

keep
these mmaped pages into memory and do not be reclaimed. At least these
pages do not be reclaimed early than file pages. I think that maybe we
can recover that routine and provide a sysctl parameter to let the user
to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially. Sometimem, someone may use mmap by reducing buffer copy compared to read
system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly. I think we can implement it by madvise and fadvise's WILLNEED option. Current implementation is just readahead if there isn't a page in memory
but I think
we can promote from inactive to active if there is already a page in memory.

Quoted 3 lines

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

Quoted 13 lines

Thank you for your advice. But I still have question about this solution. If we improve the madvise(2) and fadvise(2)'s WILLNEED option, it will cause an inconsistently status for pages that be manipulated by madvise(2) and/or fadvise(2). For example, when I call madvise with WILLNEED flag, some pages will be moved into active list if they already have been in memory, and other pages will be read into memory and be saved in inactive list if they don't be in memory. Then pages that are in inactive list are possible to be reclaim. So from the view of users, it is inconsistent because some pages are in memory and some pages are reclaimed. But actually the user hopes that all of pages can be kept in memory. IMHO, this inconsistency is weird and makes users
puzzled.

Now problem is that

1. User want to keep pages which are used once in a while in memory.
2. Kernel want to reclaim them because they are surely reclaim target pages in point of view by LRU.

The most desriable approach is that user should use mlock to guarantee them in memory. But mlock is too big overhead and user doesn't want to keep
memory all pages all at once.(Ie, he want demand paging when he need the page)
Right?

madvise, it's a just hint for kernel and kernel doesn't need to make sure madvise's behavior.
In point of view, such inconsistency might not be a big problem.

Big problem I think now is that user should use madvise(WILLNEED) periodically because such
activation happens once when user calls madvise. If user doesn't use page frequently after
user calls it, it ends up moving into inactive list and even could be reclaimed.
It's not good. :-(

Okay. How about adding new VM_WORKINGSET?
And reclaimer would give one more round trip in active/inactive list when reclaim happens
if the page is referenced.

Quoted 1 line

Sigh. We have no room for new VM_FLAG in 32 bit.

It would be nice to mark struct address_space with this flag and export AS_UNEVICTABLE somehow.
Maybe we can reuse file-locking engine for managing these bits =)

Quoted 104 lines · Konstantin Khlebnikov

Quoted 103 lines · Minchan Kim

Quoted 58 lines · Zheng Liu

Quoted 53 lines · Minchan Kim

I forgot to Ccing you.
Sorry.

---------- Forwarded message ----------
From: Minchan Kim<[email protected]>
Date: Mon, Mar 12, 2012 at 9:28 AM
Subject: Re: Control page reclaim granularity
To: Minchan Kim<[email protected]>, linux-mm<[email protected]>, linux-kernel<[email protected]>, Konstantin Khlebnikov< [email protected]>, [email protected], [email protected]

Quoted 17 lines · Zheng Liu

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel
mailing list. So please Cc me.

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the
second case, the application wants to keep mmaped page into memory and
let file pages to be reclaimed firstly. So, IMO, when application uses
mmap(2) to manipulate files, it is possible to imply that it wants

Quoted 8 lines

keep
these mmaped pages into memory and do not be reclaimed. At least these
pages do not be reclaimed early than file pages. I think that maybe we
can recover that routine and provide a sysctl parameter to let the user
to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially. Sometimem, someone may use mmap by reducing buffer copy compared to read
system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly. I think we can implement it by madvise and fadvise's WILLNEED option. Current implementation is just readahead if there isn't a page in memory
but I think
we can promote from inactive to active if there is already a page in memory.

Quoted 3 lines

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

Quoted 13 lines

Thank you for your advice. But I still have question about this solution. If we improve the madvise(2) and fadvise(2)'s WILLNEED option, it will cause an inconsistently status for pages that be manipulated by madvise(2) and/or fadvise(2). For example, when I call madvise with WILLNEED flag, some pages will be moved into active list if they already have been in memory, and other pages will be read into memory and be saved in inactive list if they don't be in memory. Then pages that are in inactive list are possible to be reclaim. So from the view of users, it is inconsistent because some pages are in memory and some pages are reclaimed. But actually the user hopes that all of pages can be kept in memory. IMHO, this inconsistency is weird and makes users
puzzled.

Now problem is that

1. User want to keep pages which are used once in a while in memory.
2. Kernel want to reclaim them because they are surely reclaim target pages in point of view by LRU.

The most desriable approach is that user should use mlock to guarantee them in memory. But mlock is too big overhead and user doesn't want to keep
memory all pages all at once.(Ie, he want demand paging when he need the page)
Right?

madvise, it's a just hint for kernel and kernel doesn't need to make sure madvise's behavior.
In point of view, such inconsistency might not be a big problem.

Big problem I think now is that user should use madvise(WILLNEED) periodically because such
activation happens once when user calls madvise. If user doesn't use page frequently after
user calls it, it ends up moving into inactive list and even could be reclaimed.
It's not good. :-(

Okay. How about adding new VM_WORKINGSET?
And reclaimer would give one more round trip in active/inactive list erwhen reclaim happens
if the page is referenced.

Quoted 5 lines

Quoted 1 line

Sigh. We have no room for new VM_FLAG in 32 bit.

p
It would be nice to mark struct address_space with this flag and export AS_UNEVICTABLE somehow.
Maybe we can reuse file-locking engine for managing these bits =)

Make sense to me. We can mark this flag in struct address_space and check it in page_refereneced_file(). If this flag is set, it will be cleard and

the function returns referenced > 1. Then this page can be promoted into activate list. But I prefer to set/clear this flag in madvise.

PS, I have subscribed linux-mm mailing list. :-)

Regards,
Zheng

Quoted 111 lines · Zheng Liu

Quoted 109 lines · Konstantin Khlebnikov

Quoted 98 lines · Minchan Kim

Quoted 58 lines · Zheng Liu

Quoted 53 lines · Minchan Kim

I forgot to Ccing you.
Sorry.

---------- Forwarded message ----------
From: Minchan Kim<[email protected]>
Date: Mon, Mar 12, 2012 at 9:28 AM
Subject: Re: Control page reclaim granularity
To: Minchan Kim<[email protected]>, linux-mm<[email protected]>, linux-kernel<[email protected]>, Konstantin Khlebnikov< [email protected]>, [email protected], [email protected]

Quoted 17 lines · Zheng Liu

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel
mailing list. So please Cc me.

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the
second case, the application wants to keep mmaped page into memory and
let file pages to be reclaimed firstly. So, IMO, when application uses
mmap(2) to manipulate files, it is possible to imply that it wants

Quoted 8 lines

keep
these mmaped pages into memory and do not be reclaimed. At least these
pages do not be reclaimed early than file pages. I think that maybe we
can recover that routine and provide a sysctl parameter to let the user
to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially. Sometimem, someone may use mmap by reducing buffer copy compared to read
system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly. I think we can implement it by madvise and fadvise's WILLNEED option. Current implementation is just readahead if there isn't a page in memory
but I think
we can promote from inactive to active if there is already a page in memory.

Quoted 3 lines

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

Quoted 13 lines

Thank you for your advice. But I still have question about this solution. If we improve the madvise(2) and fadvise(2)'s WILLNEED option, it will cause an inconsistently status for pages that be manipulated by madvise(2) and/or fadvise(2). For example, when I call madvise with WILLNEED flag, some pages will be moved into active list if they already have been in memory, and other pages will be read into memory and be saved in inactive list if they don't be in memory. Then pages that are in inactive list are possible to be reclaim. So from the view of users, it is inconsistent because some pages are in memory and some pages are reclaimed. But actually the user hopes that all of pages can be kept in memory. IMHO, this inconsistency is weird and makes users
puzzled.

Now problem is that

1. User want to keep pages which are used once in a while in memory.
2. Kernel want to reclaim them because they are surely reclaim target pages in point of view by LRU.

The most desriable approach is that user should use mlock to guarantee them in memory. But mlock is too big overhead and user doesn't want to keep
memory all pages all at once.(Ie, he want demand paging when he need the page)
Right?

madvise, it's a just hint for kernel and kernel doesn't need to make sure madvise's behavior.
In point of view, such inconsistency might not be a big problem.

Big problem I think now is that user should use madvise(WILLNEED) periodically because such
activation happens once when user calls madvise. If user doesn't use page frequently after
user calls it, it ends up moving into inactive list and even could be reclaimed.
It's not good. :-(

Quoted 6 lines

Okay. How about adding new VM_WORKINGSET?
And reclaimer would give one more round trip in active/inactive list erwhen reclaim happens
if the page is referenced.

Sigh. We have no room for new VM_FLAG in 32 bit.

p
It would be nice to mark struct address_space with this flag and export AS_UNEVICTABLE somehow.
Maybe we can reuse file-locking engine for managing these bits =)

Quoted 2 lines

Make sense to me. We can mark this flag in struct address_space and check it in page_refereneced_file(). If this flag is set, it will be cleard and

Disadvantage is that we could set reclaim granularity as per-inode. I want to set it as per-vma, not per-inode.

Quoted 3 lines

the function returns referenced> 1. Then this page can be promoted into activate list. But I prefer to set/clear this flag in madvise.

Hmm, My idea is following as,
If we can set new VM flag into VMA or something, reclaimer can check it when shrink_[in]active_list and he can prevent to deactivate/reclaim if he takes a look the page is in VMA which are set by new VM flag and the page is referenced recently at least once.
It means it gives one more round trip in his list(ie, active/inactive list)
rather than activation so that the page would become less reclaimable.

Quoted 2 lines

PS, I have subscribed linux-mm mailing list. :-)

Congratulations! :)

Quoted 3 lines

Regards,
Zheng

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email:<a href=mailto:"[email protected]"> [email protected]</a>

Quoted 112 lines · Minchan Kim

Quoted 111 lines · Zheng Liu

Quoted 109 lines · Konstantin Khlebnikov

Quoted 98 lines · Minchan Kim

Quoted 58 lines · Zheng Liu

Quoted 53 lines · Minchan Kim

I forgot to Ccing you.
Sorry.

---------- Forwarded message ----------
From: Minchan Kim<[email protected]>
Date: Mon, Mar 12, 2012 at 9:28 AM
Subject: Re: Control page reclaim granularity
To: Minchan Kim<[email protected]>, linux-mm<[email protected]>, linux-kernel<[email protected]>, Konstantin Khlebnikov< [email protected]>, [email protected], [email protected]

Quoted 17 lines · Zheng Liu

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel
mailing list. So please Cc me.

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the
second case, the application wants to keep mmaped page into memory and
let file pages to be reclaimed firstly. So, IMO, when application uses
mmap(2) to manipulate files, it is possible to imply that it wants

Quoted 8 lines

keep
these mmaped pages into memory and do not be reclaimed. At least these
pages do not be reclaimed early than file pages. I think that maybe we
can recover that routine and provide a sysctl parameter to let the user
to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially. Sometimem, someone may use mmap by reducing buffer copy compared to read
system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly. I think we can implement it by madvise and fadvise's WILLNEED option. Current implementation is just readahead if there isn't a page in memory
but I think
we can promote from inactive to active if there is already a page in memory.

Quoted 3 lines

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

Quoted 13 lines

Thank you for your advice. But I still have question about this solution. If we improve the madvise(2) and fadvise(2)'s WILLNEED option, it will cause an inconsistently status for pages that be manipulated by madvise(2) and/or fadvise(2). For example, when I call madvise with WILLNEED flag, some pages will be moved into active list if they already have been in memory, and other pages will be read into memory and be saved in inactive list if they don't be in memory. Then pages that are in inactive list are possible to be reclaim. So from the view of users, it is inconsistent because some pages are in memory and some pages are reclaimed. But actually the user hopes that all of pages can be kept in memory. IMHO, this inconsistency is weird and makes users
puzzled.

Now problem is that

1. User want to keep pages which are used once in a while in memory.
2. Kernel want to reclaim them because they are surely reclaim target pages in point of view by LRU.

The most desriable approach is that user should use mlock to guarantee them in memory. But mlock is too big overhead and user doesn't want to keep
memory all pages all at once.(Ie, he want demand paging when he need the page)
Right?

madvise, it's a just hint for kernel and kernel doesn't need to make sure madvise's behavior.
In point of view, such inconsistency might not be a big problem.

Big problem I think now is that user should use madvise(WILLNEED) periodically because such
activation happens once when user calls madvise. If user doesn't use page frequently after
user calls it, it ends up moving into inactive list and even could be reclaimed.
It's not good. :-(

Quoted 6 lines

Okay. How about adding new VM_WORKINGSET?
And reclaimer would give one more round trip in active/inactive list erwhen reclaim happens
if the page is referenced.

Sigh. We have no room for new VM_FLAG in 32 bit.

p
It would be nice to mark struct address_space with this flag and export AS_UNEVICTABLE somehow.
Maybe we can reuse file-locking engine for managing these bits =)

Quoted 5 lines

Quoted 2 lines

Make sense to me. We can mark this flag in struct address_space and check it in page_refereneced_file(). If this flag is set, it will be cleard and

Disadvantage is that we could set reclaim granularity as per-inode. I want to set it as per-vma, not per-inode.

But with per-inode flag we can tune all files, not only memory-mapped.

See, attached patch. Currently I thinking about managing code, file-locking engine really fits perfectly =)

Quoted 21 lines

Quoted 4 lines

the function returns referenced> 1. Then this page can be promoted into activate list. But I prefer to set/clear this flag in madvise.

Hmm, My idea is following as,
If we can set new VM flag into VMA or something, reclaimer can check it when shrink_[in]active_list and he can prevent to deactivate/reclaim if he takes a look the page is in VMA which are set by new VM flag and the page is referenced recently at least once.
It means it gives one more round trip in his list(ie, active/inactive list)
rather than activation so that the page would become less reclaimable.

Quoted 2 lines

PS, I have subscribed linux-mm mailing list. :-)

Congratulations! :)

Quoted 3 lines

Regards,
Zheng

Quoted 6 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email:<a href=mailto:"[email protected]"> [email protected]</a>

mm: introduce mapping AS_WORKINGSET flag

From: Konstantin Khlebnikov <[email protected]>

This patch introduces new flag AS_WORKINGSET in mapping->flags. If it set reclaimer will activates all pages for this inode after first usage.

Signed-off-by Konstantin Khlebnikov <[email protected]>

---
 include/linux/pagemap.h |   16 ++++++++++++++++
 mm/vmscan.c             |   15 ++++++++++++---
 2 files changed, 28 insertions(+), 3 deletions(-)

include/linux/pagemap.h +16 -0

index cfaaa69..c15fc17 100644
@@ -24,6 +24,7 @@ enum mapping_flags {
 	AS_ENOSPC	= __GFP_BITS_SHIFT + 1,	/* ENOSPC on async write */
 	AS_MM_ALL_LOCKS	= __GFP_BITS_SHIFT + 2,	/* under mm_take_all_locks() */
 	AS_UNEVICTABLE	= __GFP_BITS_SHIFT + 3,	/* e.g., ramdisk, SHM_LOCK */
+	AS_WORKINGSET	= __GFP_BITS_SHIFT + 4,	/* promote pages activation */
 };
 
 static inline void mapping_set_error(struct address_space *mapping, int error)

@@ -53,6 +54,21 @@ static inline int mapping_unevictable(struct address_space *mapping)
 	return !!mapping;
 }
 
+static inline void mapping_set_workingset(struct address_space *mapping)
+{
+	set_bit(AS_WORKINGSET, &mapping->flags);
+}
+
+static inline void mapping_clear_workingset(struct address_space *mapping)
+{
+	clear_bit(AS_WORKINGSET, &mapping->flags);
+}
+
+static inline int mapping_test_workingset(struct address_space *mapping)
+{
+	return mapping && test_bit(AS_WORKINGSET, &mapping->flags);
+}
+
 static inline gfp_t mapping_gfp_mask(struct address_space * mapping)
 {
 	return (__force gfp_t)mapping->flags & __GFP_BITS_MASK;

mm/vmscan.c +11 -1

index 57b9658..5ccbe8c 100644
@@ -701,6 +701,7 @@ enum page_references {
 };
 
 static enum page_references page_check_references(struct page *page,
+						  struct address_space *mapping,
 						  struct mem_cgroup_zone *mz,
 						  struct scan_control *sc)
 {

@@ -721,6 +722,13 @@ static enum page_references page_check_references(struct page *page,
 	if (vm_flags & VM_LOCKED)
 		return PAGEREF_RECLAIM;
 
+	/*
+	 * Activate workingset page if referenced at least once.
+	 */
+	if (mapping_test_workingset(mapping) &&
+	    (referenced_ptes || referenced_page))
+		return PAGEREF_ACTIVATE;
+
 	if (referenced_ptes) {
 		if (PageAnon(page))
 			return PAGEREF_ACTIVATE;

@@ -828,7 +836,9 @@ static unsigned long shrink_page_list(struct list_head *page_list,
 			}
 		}
 
-		references = page_check_references(page, mz, sc);
+		mapping = page_mapping(page);
+
+		references = page_check_references(page, mapping, mz, sc);
 		switch (references) {
 		case PAGEREF_ACTIVATE:
 			goto activate_locked;

@@ -848,11 +858,10 @@ static unsigned long shrink_page_list(struct list_head *page_list,
 				goto keep_locked;
 			if (!add_to_swap(page))

Quoted 5 lines · Konstantin Khlebnikov

Quoted 4 lines · Minchan Kim

Quoted 3 lines · Zheng Liu

Quoted 2 lines · Konstantin Khlebnikov

Quoted 1 line · Minchan Kim

On Mon, Mar 12, 2012 at 10:06:09AM +0800, Zheng Liu wrote:

Quoted 37 lines

Quoted 37 lines

Quoted 37 lines

Quoted 36 lines

Quoted 26 lines

Now problem is that

1. User want to keep pages which are used once in a while in memory.
2. Kernel want to reclaim them because they are surely reclaim target pages in point of view by LRU.

The most desriable approach is that user should use mlock to guarantee them in memory. But mlock is too big overhead and user doesn't want to keep
memory all pages all at once.(Ie, he want demand paging when he need the page)
Right?

madvise, it's a just hint for kernel and kernel doesn't need to make sure madvise's behavior.
In point of view, such inconsistency might not be a big problem.

Big problem I think now is that user should use madvise(WILLNEED) periodically because such
activation happens once when user calls madvise. If user doesn't use page frequently after
user calls it, it ends up moving into inactive list and even could be reclaimed.
It's not good. :-(

Quoted 6 lines

Okay. How about adding new VM_WORKINGSET?
And reclaimer would give one more round trip in active/inactive list erwhen reclaim happens
if the page is referenced.

Sigh. We have no room for new VM_FLAG in 32 bit.

p
It would be nice to mark struct address_space with this flag and export AS_UNEVICTABLE somehow.
Maybe we can reuse file-locking engine for managing these bits =)

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Make sense to me. We can mark this flag in struct address_space and check it in page_refereneced_file(). If this flag is set, it will be cleard and

Disadvantage is that we could set reclaim granularity as per-inode. I want to set it as per-vma, not per-inode.

But with per-inode flag we can tune all files, not only memory-mapped.

I don't oppose per-inode setting but I believe we need file range or mmapped vma, still. One file may have different characteristic part, something is working set something is streaming part.

Quoted 2 lines

See, attached patch. Currently I thinking about managing code, file-locking engine really fits perfectly =)

file-locking engine?
You consider fcntl as interface for it?
What do you mean?

Quoted 6 lines · Minchan Kim

Quoted 5 lines · Konstantin Khlebnikov

Quoted 4 lines · Minchan Kim

Quoted 3 lines · Zheng Liu

Quoted 2 lines · Konstantin Khlebnikov

Quoted 1 line · Minchan Kim

On Mon, Mar 12, 2012 at 10:06:09AM +0800, Zheng Liu wrote:

<CUT>

Quoted 49 lines

Quoted 37 lines

Quoted 37 lines

Quoted 37 lines

Quoted 36 lines

Quoted 26 lines

Now problem is that

1. User want to keep pages which are used once in a while in memory.
2. Kernel want to reclaim them because they are surely reclaim target pages in point of view by LRU.

The most desriable approach is that user should use mlock to guarantee them in memory. But mlock is too big overhead and user doesn't want to keep
memory all pages all at once.(Ie, he want demand paging when he need the page)
Right?

madvise, it's a just hint for kernel and kernel doesn't need to make sure madvise's behavior.
In point of view, such inconsistency might not be a big problem.

Big problem I think now is that user should use madvise(WILLNEED) periodically because such
activation happens once when user calls madvise. If user doesn't use page frequently after
user calls it, it ends up moving into inactive list and even could be reclaimed.
It's not good. :-(

Quoted 6 lines

Okay. How about adding new VM_WORKINGSET?
And reclaimer would give one more round trip in active/inactive list erwhen reclaim happens
if the page is referenced.

Sigh. We have no room for new VM_FLAG in 32 bit.

p
It would be nice to mark struct address_space with this flag and export AS_UNEVICTABLE somehow.
Maybe we can reuse file-locking engine for managing these bits =)

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Make sense to me. We can mark this flag in struct address_space and check it in page_refereneced_file(). If this flag is set, it will be cleard and

Disadvantage is that we could set reclaim granularity as per-inode. I want to set it as per-vma, not per-inode.

But with per-inode flag we can tune all files, not only memory-mapped.

I don't oppose per-inode setting but I believe we need file range or mmapped vma, still. One file may have different characteristic part, something is working set something is streaming part.

Quoted 7 lines

Quoted 2 lines

See, attached patch. Currently I thinking about managing code, file-locking engine really fits perfectly =)

file-locking engine?
You consider fcntl as interface for it?
What do you mean?

If we set bits on inode we somehow account its users and clear AS_WORKINGSET and AS_UNEVICTABLE at last file close. We can use file-locking engine for locking inodes in memory -- file lock automatically release inode at last fput(). Maybe it's too tricky and we should add couple simple atomic counters to generic strict inode (like i_writecount/i_readcount) but in this case we will add new code on fast-path. So, looks like invention new kind of struct file_lock is best approach.
I don't want implement range-locking for now, but I can do it if somebody really wants this.

Yes, we can use fcntl(), but fadvise() is much better.

This only a first trivial try. If this flag is set, reclaimer just give this page one more round trip rather than promote it into active list. Any comments or advices are welcomed.

Regards,
Zheng

[PATCH] mm: per-inode mmaped page reclaim

From: Zheng Liu <[email protected]>

In some cases, user wants to control mmaped page reclaim granularity. A new flag is added into struct address_space to give the page one more round trip. AS_WORKINGSET flag cannot be added in vma->vm_flags because this flag has no room for a new flag in 32 bit. Now user can call madvise(2) to set this flag for a file. If this flag is set, all pages will be given one more round trip when reclaimer tries to shrink pages.

Signed-off-by Zheng Liu <[email protected]>

---
 include/asm-generic/mman-common.h |    2 ++
 include/linux/pagemap.h           |   16 ++++++++++++++++
 mm/madvise.c                      |    8 ++++++++
 mm/vmscan.c                       |   15 +++++++++++++++
 4 files changed, 41 insertions(+), 0 deletions(-)

include/asm-generic/mman-common.h +2 -0

index 787abbb..7d26c9b 100644
@@ -48,6 +48,8 @@
 #define MADV_HUGEPAGE	14		/* Worth backing with hugepages */
 #define MADV_NOHUGEPAGE	15		/* Not worth backing with hugepages */
 
+#define MADV_WORKINGSET 16		/* give one more round trip */
+
 /* compatibility flags */
 #define MAP_FILE	0
 

include/linux/pagemap.h +16 -0

index cfaaa69..80532a0 100644
@@ -24,6 +24,7 @@ enum mapping_flags {
 	AS_ENOSPC	= __GFP_BITS_SHIFT + 1,	/* ENOSPC on async write */
 	AS_MM_ALL_LOCKS	= __GFP_BITS_SHIFT + 2,	/* under mm_take_all_locks() */
 	AS_UNEVICTABLE	= __GFP_BITS_SHIFT + 3,	/* e.g., ramdisk, SHM_LOCK */
+	AS_WORKINGSET	= __GFP_BITS_SHIFT + 4, /* give one more round trip */
 };
 
 static inline void mapping_set_error(struct address_space *mapping, int error)

@@ -36,6 +37,21 @@ static inline void mapping_set_error(struct address_space *mapping, int error)
 	}
 }
 
+static inline void mapping_set_workingset(struct address_space *mapping)
+{
+	set_bit(AS_WORKINGSET, &mapping->flags);
+}
+
+static inline void mapping_clear_workingset(struct address_space *mapping)
+{
+	clear_bit(AS_WORKINGSET, &mapping->flags);
+}
+
+static inline int mapping_test_workingset(struct address_space *mapping)
+{
+	return mapping && test_bit(AS_WORKINGSET, &mapping->flags);
+}
+
 static inline void mapping_set_unevictable(struct address_space *mapping)
 {
 	set_bit(AS_UNEVICTABLE, &mapping->flags);

mm/madvise.c +8 -0

index 74bf193..8ca6c9b 100644
@@ -77,6 +77,14 @@ static long madvise_behavior(struct vm_area_struct * vma,
 		if (error)
 			goto out;
 		break;
+	case MADV_WORKINGSET:
+		if (vma->vm_file && vma->vm_file->f_mapping) {
+			mapping_set_workingset(vma->vm_file->f_mapping);
+		} else {
+			error = -EPERM;
+			goto out;
+		}
+		break;
 	}
 
 	if (new_flags == vma->vm_flags) {

mm/vmscan.c +15 -0

index c52b235..51f745b 100644
@@ -721,6 +721,15 @@ static enum page_references page_check_references(struct page *page,
 	if (vm_flags & VM_LOCKED)
 		return PAGEREF_RECLAIM;
 
+	/*
+	 * give this page one more round trip because workingset
+	 * flag is set.
+	 */
+	if (mapping_test_workingset(page_mapping(page))) {
+		mapping_clear_workingset(page_mapping(page));
+		return PAGEREF_KEEP;
+	}
+
 	if (referenced_ptes) {
 		if (PageAnon(page))
 			return PAGEREF_ACTIVATE;

@@ -1737,6 +1746,12 @@ static void shrink_active_list(unsigned long nr_to_scan,
 			continue;
 		}
 
+		if (mapping_test_workingset(page_mapping(page))) {
+			mapping_clear_workingset(page_mapping(page));
+			list_add(&page->lru, &l_active);
+			continue;
+		}
+
 		if (page_referenced(page, 0, mz->mem_cgroup, &vm_flags)) {
 			nr_rotated += hpage_nr_pages(page);
 			/*

Signature · 1 line

1.7.4.1

Sorry, please forgive me. This patch has a defect. When one page is scaned and flag is clear, all other's flags also are clear too.

Hi,

I noticed this discussion and decided to pitch in one small idea from my side.

It would be nice to range lock an inode's pages by storing those ranges which would be locked.
This could also add some good routines for the kernel in terms of range locking for a single inode.
However, wouldn't this add some overhead to shrink_page_list() since that code would need to go through
all these ranges while trying to reclaim a single page ?

One small suggestion from my side is:
Why don't we implement something like : "Complete page-cache reclaim control from usermode"?
In this, we can set/unset the mapping to AS_UNEVICTABLE (as Konstantin mentioned) for a file's
inode from usermode by using ioctl or fcntl or maybe even go as far as implementing an O_NORECL
option to the open system call.

After setting the AS_UNEVICTABLE, the usermode application can choose to keep and remove pages by
using the fadvise(WILLNEED) and fadvise(DONTNEED).

( I think maybe the presence of any VMA is might not really be required for this idea. )

Thanks,
Kautuk.

Quoted 12 lines · Kautuk Consul

Hi,

I noticed this discussion and decided to pitch in one small idea from my side.

It would be nice to range lock an inode's pages by storing those ranges which would be locked.
This could also add some good routines for the kernel in terms of range locking for a single inode.
However, wouldn't this add some overhead to shrink_page_list() since that code would need to go through
all these ranges while trying to reclaim a single page ?

Quoted 9 lines

One small suggestion from my side is:
Why don't we implement something like : "Complete page-cache reclaim control from usermode"?
In this, we can set/unset the mapping to AS_UNEVICTABLE (as Konstantin mentioned) for a file's
inode from usermode by using ioctl or fcntl or maybe even go as far as implementing an O_NORECL
option to the open system call.

Of course, only an application executing with root privileges should be allowed to set the inode's
mapping flags in this manner.

Quoted 11 lines

After setting the AS_UNEVICTABLE, the usermode application can choose to keep and remove pages by
using the fadvise(WILLNEED) and fadvise(DONTNEED).

( I think maybe the presence of any VMA is might not really be required for this idea. )

Thanks,
Kautuk.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hi Kautuk,

IMHO, running application with root privilege is too dangerous.  We should avoid it.

I agree, but that's not my point.

All I'm saying is that we probably don't want to give normal unprivileged usermode apps
the capability to set the mapping to AS_UNEVICTABLE as anyone can then write an application
that hogs memory without allowing the kernel to free it through memory reclaim.

Quoted 8 lines

I agree, but that's not my point.

All I'm saying is that we probably don't want to give normal unprivileged usermode apps
the capability to set the mapping to AS_UNEVICTABLE as anyone can then write an application
that hogs memory without allowing the kernel to free it through memory reclaim.

Sorry, I mean :
"... that hogs kernel unmapped page-cache memory without allowing the kernel to free it through memory reclaim."

Yes, I think so.  But it seems that there has some codes that are possible to be abused.  For example, as I said previously, applications can mmap a normal data file with PROT_EXEC flag.  Then this file gets a high priority to keep in memory (commit: 8cab4754).  So my point is that we cannot control applications how to use these mechanisms.  We just provide them and let applications to choose how to use them. :-)

The only problem that might happen might be in OOM because we will have to include selection points for
these page-cache pages (proportionately) while finding the most expensive process to kill.
( I'm talking about the page-cache pages which are not mapped to usermode page-tables at all. )

If any usermode application reads in an extremely huge file, whose inode has been set to AS_UNEVICTABLE,
we might want to kill those applications that read in those pages(proportionately) so that the guilty application can be killed.

Quoted 111 lines · Zheng Liu

Quoted 109 lines · Konstantin Khlebnikov

Quoted 98 lines · Minchan Kim

Quoted 58 lines · Zheng Liu

Quoted 53 lines · Minchan Kim

I forgot to Ccing you.
Sorry.

---------- Forwarded message ----------
From: Minchan Kim<[email protected]>
Date: Mon, Mar 12, 2012 at 9:28 AM
Subject: Re: Control page reclaim granularity
To: Minchan Kim<[email protected]>, linux-mm<[email protected]>, linux-kernel<[email protected]>, Konstantin Khlebnikov< [email protected]>, [email protected], [email protected]

Quoted 17 lines · Zheng Liu

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel
mailing list. So please Cc me.

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the
second case, the application wants to keep mmaped page into memory and
let file pages to be reclaimed firstly. So, IMO, when application uses
mmap(2) to manipulate files, it is possible to imply that it wants

Quoted 8 lines

keep
these mmaped pages into memory and do not be reclaimed. At least these
pages do not be reclaimed early than file pages. I think that maybe we
can recover that routine and provide a sysctl parameter to let the user
to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially. Sometimem, someone may use mmap by reducing buffer copy compared to read
system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly. I think we can implement it by madvise and fadvise's WILLNEED option. Current implementation is just readahead if there isn't a page in memory
but I think
we can promote from inactive to active if there is already a page in memory.

Quoted 3 lines

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

Quoted 13 lines

Thank you for your advice. But I still have question about this solution. If we improve the madvise(2) and fadvise(2)'s WILLNEED option, it will cause an inconsistently status for pages that be manipulated by madvise(2) and/or fadvise(2). For example, when I call madvise with WILLNEED flag, some pages will be moved into active list if they already have been in memory, and other pages will be read into memory and be saved in inactive list if they don't be in memory. Then pages that are in inactive list are possible to be reclaim. So from the view of users, it is inconsistent because some pages are in memory and some pages are reclaimed. But actually the user hopes that all of pages can be kept in memory. IMHO, this inconsistency is weird and makes users
puzzled.

Now problem is that

1. User want to keep pages which are used once in a while in memory.
2. Kernel want to reclaim them because they are surely reclaim target pages in point of view by LRU.

The most desriable approach is that user should use mlock to guarantee them in memory. But mlock is too big overhead and user doesn't want to keep
memory all pages all at once.(Ie, he want demand paging when he need the page)
Right?

madvise, it's a just hint for kernel and kernel doesn't need to make sure madvise's behavior.
In point of view, such inconsistency might not be a big problem.

Big problem I think now is that user should use madvise(WILLNEED) periodically because such
activation happens once when user calls madvise. If user doesn't use page frequently after
user calls it, it ends up moving into inactive list and even could be reclaimed.
It's not good. :-(

Quoted 6 lines

Okay. How about adding new VM_WORKINGSET?
And reclaimer would give one more round trip in active/inactive list erwhen reclaim happens
if the page is referenced.

Sigh. We have no room for new VM_FLAG in 32 bit.

p
It would be nice to mark struct address_space with this flag and export AS_UNEVICTABLE somehow.
Maybe we can reuse file-locking engine for managing these bits =)

Quoted 2 lines

Make sense to me. We can mark this flag in struct address_space and check it in page_refereneced_file(). If this flag is set, it will be cleard and

Disadvantage is that we could set reclaim granularity as per-inode. I want to set it as per-vma, not per-inode.

Quoted 3 lines

the function returns referenced > 1. Then this page can be promoted into activate list. But I prefer to set/clear this flag in madvise.

Hmm, My idea is following as,
If we can set new VM flag into VMA or something, reclaimer can check it when shrink_[in]active_list and he can prevent to deactivate/reclaim if he takes a look the page is in VMA which are set by new VM flag and the page is referenced recently at least once.
It means it gives one more round trip in his list(ie, active/inactive list)
rather than activation so that the page would become less reclaimable.

Quoted 115 lines · Minchan Kim

Quoted 113 lines · Zheng Liu

Quoted 104 lines · Konstantin Khlebnikov

Quoted 103 lines · Minchan Kim

Quoted 58 lines · Zheng Liu

Quoted 53 lines · Minchan Kim

I forgot to Ccing you.
Sorry.

---------- Forwarded message ----------
From: Minchan Kim<[email protected]>
Date: Mon, Mar 12, 2012 at 9:28 AM
Subject: Re: Control page reclaim granularity
To: Minchan Kim<[email protected]>, linux-mm<[email protected]>, linux-kernel<[email protected]>, Konstantin Khlebnikov< [email protected]>, [email protected], [email protected]

Quoted 17 lines · Zheng Liu

Hi Minchan,

Sorry, I forgot to say that I don't subscribe linux-mm and linux-kernel
mailing list. So please Cc me.

IMHO, maybe we should re-think about how does user use mmap(2). I describe the cases I known in our product system. They can be categorized into two cases. One is mmaped all data files into memory and sometime it uses write(2) to append some data, and another uses mmap(2)/munmap(2) and read(2)/write(2) to manipulate the files. In the
second case, the application wants to keep mmaped page into memory and
let file pages to be reclaimed firstly. So, IMO, when application uses
mmap(2) to manipulate files, it is possible to imply that it wants

Quoted 8 lines

keep
these mmaped pages into memory and do not be reclaimed. At least these
pages do not be reclaimed early than file pages. I think that maybe we
can recover that routine and provide a sysctl parameter to let the user
to set this ratio between mmaped pages and file pages.

I am not convinced why we should handle mapped page specially. Sometimem, someone may use mmap by reducing buffer copy compared to read
system call.
So I think we can't make sure mmaped pages are always win.

My suggestion is that it would be better to declare by user explicitly. I think we can implement it by madvise and fadvise's WILLNEED option. Current implementation is just readahead if there isn't a page in memory
but I think
we can promote from inactive to active if there is already a page in memory.

Quoted 3 lines

It's more clear and it couldn't be affected by kernel page reclaim algorithm change
like this.

Quoted 13 lines

Thank you for your advice. But I still have question about this solution. If we improve the madvise(2) and fadvise(2)'s WILLNEED option, it will cause an inconsistently status for pages that be manipulated by madvise(2) and/or fadvise(2). For example, when I call madvise with WILLNEED flag, some pages will be moved into active list if they already have been in memory, and other pages will be read into memory and be saved in inactive list if they don't be in memory. Then pages that are in inactive list are possible to be reclaim. So from the view of users, it is inconsistent because some pages are in memory and some pages are reclaimed. But actually the user hopes that all of pages can be kept in memory. IMHO, this inconsistency is weird and makes users
puzzled.

Now problem is that

1. User want to keep pages which are used once in a while in memory.
2. Kernel want to reclaim them because they are surely reclaim target pages in point of view by LRU.

The most desriable approach is that user should use mlock to guarantee them in memory. But mlock is too big overhead and user doesn't want to keep
memory all pages all at once.(Ie, he want demand paging when he need the page)
Right?

madvise, it's a just hint for kernel and kernel doesn't need to make sure madvise's behavior.
In point of view, such inconsistency might not be a big problem.

Big problem I think now is that user should use madvise(WILLNEED) periodically because such
activation happens once when user calls madvise. If user doesn't use page frequently after
user calls it, it ends up moving into inactive list and even could be reclaimed.
It's not good. :-(

Okay. How about adding new VM_WORKINGSET?
And reclaimer would give one more round trip in active/inactive list erwhen reclaim happens
if the page is referenced.

Quoted 5 lines

Quoted 1 line

Sigh. We have no room for new VM_FLAG in 32 bit.

p
It would be nice to mark struct address_space with this flag and export AS_UNEVICTABLE somehow.
Maybe we can reuse file-locking engine for managing these bits =)

Make sense to me. We can mark this flag in struct address_space and check it in page_refereneced_file(). If this flag is set, it will be cleard and

Quoted 2 lines

Disadvantage is that we could set reclaim granularity as per-inode. I want to set it as per-vma, not per-inode.

I don't think this is a disadvantage. This per-inode reclaim granularity is useful for us. Actually I have thought to implement a per-inode memcg to let different file sets to be reclaimed separately. So maybe we can provide two mechanisms to let the user to choose how to use them.

Quoted 11 lines

Quoted 4 lines

the function returns referenced > 1. Then this page can be promoted into activate list. But I prefer to set/clear this flag in madvise.

Hmm, My idea is following as,
If we can set new VM flag into VMA or something, reclaimer can check it when shrink_[in]active_list and he can prevent to deactivate/reclaim if he takes a look the page is in VMA which are set by new VM flag and the page is referenced recently at least once.
It means it gives one more round trip in his list(ie, active/inactive list)
rather than activation so that the page would become less reclaimable.

No matter what the page is given one more round trip or is promoted into active list, it can satisfy our current requirement. So now the question is which is better. If we add a new VM flag, as you said before, vma->vm_flags has no room for it in 32 bit. I have noticed that this topic has been discussed [1] and the result is that vm_flags is still a unsigned long type. So we need to use a tricky technique to solve it. If we add a new flag in struct addpress_space, it might be easy to implement it.

1. http://lkml.indiana.edu/hypermail/linux/kernel/1104.1/00975.html

Regards,
Zheng

Quoted 8 lines · Zheng Liu

Hi list,

Recently we encounter a problem about page reclaim. I abstract it in here. The problem is that there are two different file types. One is small index file, and another is large data file. The index file is mmaped into memory, and application hope that they can be kept in memory and don't be reclaimed too frequently. The data file is manipulted by read/write, and they should be reclaimed more frequently than the index file.

I think it's a regression since 2.6.28.
Before we were trying to keep mapped pages in memory(See calc_reclaim_mapped). But we removed that routine when we applied split lru page replacement. Rik, KOSAKI. What's the rationale?

Quoted 9 lines · Minchan Kim

Quoted 8 lines · Zheng Liu

Hi list,

Recently we encounter a problem about page reclaim. I abstract it in here. The problem is that there are two different file types. One is small index file, and another is large data file. The index file is mmaped into memory, and application hope that they can be kept in memory and don't be reclaimed too frequently. The data file is manipulted by read/write, and they should be reclaimed more frequently than the index file.

They should indeed be. The data pages should not get promoted to the active list unless they get referenced twice while on the inactive list.

Mmaped pages, on the other hand, get promoted to the active list after just one reference.

Also, as long as the inactive file list is larger than the active file list, we do not reclaim active file pages at all.

Quoted 5 lines

I think it's a regression since 2.6.28.
Before we were trying to keep mapped pages in memory(See calc_reclaim_mapped). But we removed that routine when we applied split lru page replacement. Rik, KOSAKI. What's the rationale?

One main reason is scalability. We have to treat pages in such a way that we do not have to search through gigabytes of memory to find a few eviction candidates to place on the inactive list - where they could get reused and stopped from eviction again.

Signature · 2 lines

-- 
All rights reversed

Quoted 11 lines · Rik van Riel

Quoted 3 lines · Minchan Kim

Before we were trying to keep mapped pages in memory(See calc_reclaim_mapped). But we removed that routine when we applied split lru page replacement. Rik, KOSAKI. What's the rationale?

One main reason is scalability. We have to treat pages in such a way that we do not have to search through gigabytes of memory to find a few eviction candidates to place on the inactive list - where they could get reused and stopped from eviction again.

Okay. Thanks, Rik.
Then, another question.
Why did we handle mmaped page specially at that time? Just out of curiosity.