On Tue 06-04-21 23:12:34, Neil Sun wrote:
>
>
> On 2021/4/6 22:39, Michal Hocko wrote:
> >
> > Have you considered using high limit for the pro-active memory reclaim?
>
> Thanks, Michal, do you mean the procfs interfaces?
> We have set vm.vfs_cache_pressure=1000 and so on.
> would you please ta
On 2021/4/6 22:39, Michal Hocko wrote:
Have you considered using high limit for the pro-active memory reclaim?
Thanks, Michal, do you mean the procfs interfaces?
We have set vm.vfs_cache_pressure=1000 and so on.
would you please take an example?
--
Neil
On Tue 06-04-21 22:34:02, Neil Sun wrote:
>
>
> On 2021/4/6 19:39, Michal Hocko wrote:
> > On Tue 06-04-21 19:30:22, Neil Sun wrote:
> > > On 2021/4/6 15:21, Michal Hocko wrote:
> > > >
> > > > You are changing semantic of the existing user interface. This knob has
> > > > never been memcg aware
On 2021/4/6 19:39, Michal Hocko wrote:
On Tue 06-04-21 19:30:22, Neil Sun wrote:
On 2021/4/6 15:21, Michal Hocko wrote:
You are changing semantic of the existing user interface. This knob has
never been memcg aware and it is supposed to have a global impact. I do
not think we can simply cha
On Tue 06-04-21 19:30:22, Neil Sun wrote:
> On 2021/4/6 15:21, Michal Hocko wrote:
> >
> > You are changing semantic of the existing user interface. This knob has
> > never been memcg aware and it is supposed to have a global impact. I do
> > not think we can simply change that without some users
On Fri 02-04-21 18:38:54, Neil Sun wrote:
> This patch makes shrink_slab() with task's memcg in drop_slab_node(),
> so we can free reclaimable slab objects belongs to memcg /lxc/i-vbe1u8o7
> with following command:
You are changing semantic of the existing user interface. This knob has
never been
Hi Neil,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.12-rc5]
[also build test ERROR on next-20210401]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--
Hi Neil,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.12-rc5]
[also build test ERROR on next-20210401]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--
This patch makes shrink_slab() with task's memcg in drop_slab_node(),
so we can free reclaimable slab objects belongs to memcg /lxc/i-vbe1u8o7
with following command:
cgexec -g memory:/lxc/i-vbe1u8o7 sysctl vm.drop_caches=2
Test with following steps:
root@i-yl0pwrt8:~# free -h
tota
On 09.06.20 20:51, dylan-meiners wrote:
> Changed "optizimation" to "optimization".
>
> Signed-off-by: dylan-meiners
> ---
> mm/vmscan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index b6d84326bdf2..8ac7bf9c3c43 100644
> --- a/mm/vmscan
Changed "optizimation" to "optimization".
Signed-off-by: dylan-meiners
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b6d84326bdf2..8ac7bf9c3c43 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -914,7 +914,7 @@ static int __remove
On Fri, May 24, 2019 at 01:36:01PM +0530, Sahitya Tummala wrote:
> This is important for the scenario where FBE (file based encryption)
> is enabled. With FBE, the encryption context needed to en/decrypt a file
> will be stored in inode and any inode that is left in the cache after
> drop_caches is
On Fri, May 24, 2019 at 4:06 PM Sahitya Tummala wrote:
>
> This is important for the scenario where FBE (file based encryption)
> is enabled. With FBE, the encryption context needed to en/decrypt a file
> will be stored in inode and any inode that is left in the cache after
> drop_caches is done w
This is important for the scenario where FBE (file based encryption)
is enabled. With FBE, the encryption context needed to en/decrypt a file
will be stored in inode and any inode that is left in the cache after
drop_caches is done will be a problem. For ex, in Android, drop_caches
will be used whe
On Tue, Jun 17, 2014 at 12:55:02PM +0800, Chen Yucong wrote:
> Via https://lkml.org/lkml/2013/4/10/897, we can know that the relative design
> idea is to keep
>
> scan_target[anon] : scan_target[file]
> == really_scanned_num[anon] : really_scanned_num[file]
>
> But we can find the fol
On Thu, Jun 19, 2014 at 01:13:22PM -0700, Andrew Morton wrote:
> On Thu, 19 Jun 2014 10:02:39 +0900 Minchan Kim wrote:
>
> > > > @@ -2057,8 +2057,7 @@ out:
> > > > static void shrink_lruvec(struct lruvec *lruvec, struct scan_control
> > > > *sc)
> > > > {
> > > > unsigned long nr[NR_LRU
On Thu, 19 Jun 2014 10:02:39 +0900 Minchan Kim wrote:
> > > @@ -2057,8 +2057,7 @@ out:
> > > static void shrink_lruvec(struct lruvec *lruvec, struct scan_control
> > > *sc)
> > > {
> > > unsigned long nr[NR_LRU_LISTS];
> > > - unsigned long targets[NR_LRU_LISTS];
> > > - uns
Hello Andrew,
On Wed, Jun 18, 2014 at 05:40:01PM -0700, Andrew Morton wrote:
> On Thu, 19 Jun 2014 08:04:32 +0800 Chen Yucong wrote:
>
> > On Wed, 2014-06-18 at 15:27 -0700, Andrew Morton wrote:
> > > On Tue, 17 Jun 2014 12:55:02 +0800 Chen Yucong wrote:
> > >
> > > > diff --git a/mm/vmscan.c
On Thu, 19 Jun 2014 08:04:32 +0800 Chen Yucong wrote:
> On Wed, 2014-06-18 at 15:27 -0700, Andrew Morton wrote:
> > On Tue, 17 Jun 2014 12:55:02 +0800 Chen Yucong wrote:
> >
> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index a8ffe4e..2c35e34 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/v
On Wed, 2014-06-18 at 15:27 -0700, Andrew Morton wrote:
> On Tue, 17 Jun 2014 12:55:02 +0800 Chen Yucong wrote:
>
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index a8ffe4e..2c35e34 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -2087,8 +2086,8 @@ static void shrink_lruvec(struct lru
On Tue, 17 Jun 2014 12:55:02 +0800 Chen Yucong wrote:
> Via https://lkml.org/lkml/2013/4/10/897, we can know that the relative design
> idea is to keep
>
> scan_target[anon] : scan_target[file]
> == really_scanned_num[anon] : really_scanned_num[file]
>
> But we can find the followin
On 06/18/2014 11:08 AM, Chen Yucong wrote:
> On Wed, 2014-06-18 at 11:00 +0200, Jerome Marchand wrote:
>>> if (!nr_file || !nr_anon)
>>> break;
>>>
>>> - if (nr_file > nr_anon) {
>>> - unsigned long scan_target =
>> targets[LRU_I
On Wed, 2014-06-18 at 11:00 +0200, Jerome Marchand wrote:
> > if (!nr_file || !nr_anon)
> > break;
> >
> > - if (nr_file > nr_anon) {
> > - unsigned long scan_target =
> targets[LRU_INACTIVE_ANON] +
> >
> -
On 06/17/2014 06:55 AM, Chen Yucong wrote:
> Via https://lkml.org/lkml/2013/4/10/897, we can know that the relative design
> idea is to keep
>
> scan_target[anon] : scan_target[file]
> == really_scanned_num[anon] : really_scanned_num[file]
>
> But we can find the following snippet in
Via https://lkml.org/lkml/2013/4/10/897, we can know that the relative design
idea is to keep
scan_target[anon] : scan_target[file]
== really_scanned_num[anon] : really_scanned_num[file]
But we can find the following snippet in shrink_lruvec():
if (nr_file > nr_anon) {
..
On Mon, 2014-06-16 at 16:42 -0700, Andrew Morton wrote:
> On Mon, 16 Jun 2014 20:57:54 +0800 Chen Yucong wrote:
>
> > On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote:
> > > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> > > original scan targets introduces extra 4
On Mon, Jun 16, 2014 at 04:42:37PM -0700, Andrew Morton wrote:
> On Mon, 16 Jun 2014 20:57:54 +0800 Chen Yucong wrote:
>
> > On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote:
> > > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> > > original scan targets introduces
On Mon, Jun 16, 2014 at 08:57:54PM +0800, Chen Yucong wrote:
> On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote:
> > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> > original scan targets introduces extra 40 bytes on the stack. This patch
> > is able to avoid this si
On Mon, 16 Jun 2014 20:57:54 +0800 Chen Yucong wrote:
> On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote:
> > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> > original scan targets introduces extra 40 bytes on the stack. This patch
> > is able to avoid this situati
On Mon, 2014-06-09 at 21:27 +0800, Chen Yucong wrote:
> Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> original scan targets introduces extra 40 bytes on the stack. This patch
> is able to avoid this situation and the call to memcpy(). At the same time,
> it does not cha
On Sun, 2014-06-15 at 17:47 -0700, Hugh Dickins wrote:
> On Wed, 11 Jun 2014, Chen Yucong wrote:
> > On Tue, 2014-06-10 at 16:33 -0700, Andrew Morton wrote:
> > > > break;
> > > >
> > > > if (nr_file > nr_anon) {
> > > > - unsigned long scan
On Wed, 11 Jun 2014, Chen Yucong wrote:
> On Tue, 2014-06-10 at 16:33 -0700, Andrew Morton wrote:
> > > break;
> > >
> > > if (nr_file > nr_anon) {
> > > - unsigned long scan_target =
> > targets[LRU_INACTIVE_ANON] +
> > >
> > -
On Thu, 12 Jun 2014 17:36:35 +0800 Chen Yucong wrote:
> shrink_page_list() has too many arguments that have already reached ten.
> Some of those arguments and temporary variables introduces extra 80 bytes
> on the stack.
>
> This patch wraps five parameters into arg_container and removes some te
On Thu, 2014-06-12 at 08:45 -0400, Rik van Riel wrote:
> > shrink_page_list() has too many arguments that have already reached
> ten.
> > Some of those arguments and temporary variables introduces extra 80
> bytes
> > on the stack.
> >
> > This patch wraps five parameters into arg_container and re
On 06/12/2014 05:36 AM, Chen Yucong wrote:
> shrink_page_list() has too many arguments that have already reached ten.
> Some of those arguments and temporary variables introduces extra 80 bytes
> on the stack.
>
> This patch wraps five parameters into arg_container and removes some temporary
> var
shrink_page_list() has too many arguments that have already reached ten.
Some of those arguments and temporary variables introduces extra 80 bytes
on the stack.
This patch wraps five parameters into arg_container and removes some temporary
variables, thus making shrink_page_list() to consume fewer
On Tue, 2014-06-10 at 16:33 -0700, Andrew Morton wrote:
> > break;
> >
> > if (nr_file > nr_anon) {
> > - unsigned long scan_target =
> targets[LRU_INACTIVE_ANON] +
> >
> - targets[LRU_ACTIVE_ANON]
On Tue, 2014-06-10 at 16:33 -0700, Andrew Morton wrote:
> On Mon, 9 Jun 2014 21:27:16 +0800 Chen Yucong wrote:
>
> > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> > original scan targets introduces extra 40 bytes on the stack. This patch
> > is able to avoid this sit
On Mon, 9 Jun 2014 21:27:16 +0800 Chen Yucong wrote:
> Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> original scan targets introduces extra 40 bytes on the stack. This patch
> is able to avoid this situation and the call to memcpy(). At the same time,
> it does not c
On Tue, Jun 10, 2014 at 08:10:51AM +0800, Chen Yucong wrote:
> On Tue, 2014-06-10 at 08:24 +0900, Minchan Kim wrote:
> > Hello,
> >
> > On Mon, Jun 09, 2014 at 09:27:16PM +0800, Chen Yucong wrote:
> > > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> > > original scan ta
On Tue, 2014-06-10 at 08:24 +0900, Minchan Kim wrote:
> Hello,
>
> On Mon, Jun 09, 2014 at 09:27:16PM +0800, Chen Yucong wrote:
> > Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> > original scan targets introduces extra 40 bytes on the stack. This patch
> > is able to a
Hello,
On Mon, Jun 09, 2014 at 09:27:16PM +0800, Chen Yucong wrote:
> Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
> original scan targets introduces extra 40 bytes on the stack. This patch
> is able to avoid this situation and the call to memcpy(). At the same time,
>
Via https://lkml.org/lkml/2013/4/10/334 , we can find that recording the
original scan targets introduces extra 40 bytes on the stack. This patch
is able to avoid this situation and the call to memcpy(). At the same time,
it does not change the relative design idea.
ratio = original_nr_file / orig
On Mon, May 19, 2014 at 12:08:30PM +0800, Jianyu Zhan wrote:
> Currently, we use (zone->managed_pages + KSWAPD_ZONE_BALANCE_GAP_RATIO-1) /
> KSWAPD_ZONE_BALANCE_GAP_RATIO to avoid a zero gap value. It's better to
> use DIV_ROUND_UP macro for neater code and clear meaning.
>
> Besides, the gap valu
On 05/19/2014 12:08 AM, Jianyu Zhan wrote:
> Currently, we use (zone->managed_pages + KSWAPD_ZONE_BALANCE_GAP_RATIO-1) /
> KSWAPD_ZONE_BALANCE_GAP_RATIO to avoid a zero gap value. It's better to
> use DIV_ROUND_UP macro for neater code and clear meaning.
>
> Besides, the gap value is calculated ag
Currently, we use (zone->managed_pages + KSWAPD_ZONE_BALANCE_GAP_RATIO-1) /
KSWAPD_ZONE_BALANCE_GAP_RATIO to avoid a zero gap value. It's better to
use DIV_ROUND_UP macro for neater code and clear meaning.
Besides, the gap value is calculated against the per-zone "managed pages",
not "present page
On 07/08/2013 02:43 PM, Chen Gang wrote:
> On 07/05/2013 12:06 PM, Chen Gang wrote:
>> On 06/19/2013 03:19 PM, Chen Gang wrote:
>>> On 06/19/2013 03:10 PM, Andrew Morton wrote:
On Wed, 19 Jun 2013 14:55:13 +0800 Chen Gang wrote:
>>
>> 'lru' may be used without initialized, so nee
On 07/05/2013 12:06 PM, Chen Gang wrote:
> On 06/19/2013 03:19 PM, Chen Gang wrote:
>> On 06/19/2013 03:10 PM, Andrew Morton wrote:
>>> On Wed, 19 Jun 2013 14:55:13 +0800 Chen Gang wrote:
>>>
>
> 'lru' may be used without initialized, so need regressing part of the
> related patch.
>>>
On 06/19/2013 04:53 PM, Mel Gorman wrote:
> On Wed, Jun 19, 2013 at 02:55:13PM +0800, Chen Gang wrote:
>> >
>> > 'lru' may be used without initialized, so need regressing part of the
>> > related patch.
>> >
>> > The related patch:
>> > "3abf380 mm: remove lru parameter from __lru_cache_add and
On Wed, Jun 19, 2013 at 02:55:13PM +0800, Chen Gang wrote:
>
> 'lru' may be used without initialized, so need regressing part of the
> related patch.
>
> The related patch:
> "3abf380 mm: remove lru parameter from __lru_cache_add and
> lru_cache_add_lru"
>
>
> Signed-off-by: Chen Gang
> ---
On 06/19/2013 03:10 PM, Andrew Morton wrote:
> On Wed, 19 Jun 2013 14:55:13 +0800 Chen Gang wrote:
>
>> >
>> > 'lru' may be used without initialized, so need regressing part of the
>> > related patch.
>> >
>> > The related patch:
>> > "3abf380 mm: remove lru parameter from __lru_cache_add and
On Wed, 19 Jun 2013 14:55:13 +0800 Chen Gang wrote:
>
> 'lru' may be used without initialized, so need regressing part of the
> related patch.
>
> The related patch:
> "3abf380 mm: remove lru parameter from __lru_cache_add and
> lru_cache_add_lru"
>
> ...
>
> --- a/mm/vmscan.c
> +++ b/mm/vms
'lru' may be used without initialized, so need regressing part of the
related patch.
The related patch:
"3abf380 mm: remove lru parameter from __lru_cache_add and lru_cache_add_lru"
Signed-off-by: Chen Gang
---
mm/vmscan.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --g
On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-mm1:
>...
> +lumpy-reclaim-v2.patch
>...
> Teach page reclaim to perform a short physical scan to try to generate free
> higher-order pages. Needs work.
>...
This patch makes the needlessly global __isola
Hi !
I think we don't need a 'bug()' return from 'pte'.
--- vmscan.c.oldThu Oct 19 23:22:15 2000
+++ vmscan.cFri Oct 20 03:24:10 2000
@@ -98,10 +98,6 @@
if (PageSwapCache(page)) {
entry.val = page->index;
swap_duplicate(entry);
-
55 matches
Mail list logo
