[PATCH][RFC] memory.min_usage again

[PATCH][RFC] memory.min_usage again

[YAMAMOTO Takashi]

hi,

> hi,
> 
> here's a patch to implement memory.min_usage,
> which controls the minimum memory usage for a cgroup.
> 
> it works similarly to mlock;
> global memory reclamation doesn't reclaim memory from
> cgroups whose memory usage is below the value.
> setting it too high is a dangerous operation.
> 
> it's against 2.6.24-rc3-mm2 + memory.swappiness patch i posted here yesterday.
> but it's logically independent from the swappiness patch.
> 
> todo:
> - restrict non-root user's operation ragardless of owner of cgroupfs files?
> - make oom killer aware of this?
> 
> YAMAMOTO Takashi

here's a new version adapted to 2.6.27-rc5-mm1.

YAMAMOTO Takashi


Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
---

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index ee1b2fc..fdf35bf 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -72,6 +72,8 @@ extern void mem_cgroup_record_reclaim_priority(struct mem_cgroup *mem,
 extern long mem_cgroup_calc_reclaim(struct mem_cgroup *mem, struct zone *zone,
 					int priority, enum lru_list lru);
 
+extern int mem_cgroup_canreclaim(struct page *page, struct mem_cgroup *mem);
+
 #else /* CONFIG_CGROUP_MEM_RES_CTLR */
 static inline void page_reset_bad_cgroup(struct page *page)
 {
@@ -163,6 +165,13 @@ static inline long mem_cgroup_calc_reclaim(struct mem_cgroup *mem,
 {
 	return 0;
 }
+
+static inline int mem_cgroup_canreclaim(struct page *page,
+					struct mem_cgroup *mem)
+{
+	return 1;
+}
+
 #endif /* CONFIG_CGROUP_MEM_CONT */
 
 #endif /* _LINUX_MEMCONTROL_H */
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2979d22..a567bdb 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -129,6 +129,7 @@ struct mem_cgroup {
 	struct mem_cgroup_lru_info info;
 
 	int	prev_priority;	/* for recording reclaim priority */
+	unsigned long long min_usage; /* XXX should be a part of res_counter? */
 	/*
 	 * statistics.
 	 */
@@ -1004,6 +1005,28 @@ static int mem_control_stat_show(struct cgroup *cont, struct cftype *cft,
 	return 0;
 }
 
+static int mem_cgroup_min_usage_write(struct cgroup *cg, struct cftype *cft,
+			    const char *buffer)
+{
+	struct mem_cgroup *mem = mem_cgroup_from_cont(cg);
+	unsigned long long val;
+	int error;
+
+	error = res_counter_memparse_write_strategy(buffer, &val);
+	if (error)
+		return error;
+
+	mem->min_usage = val;
+	return 0;
+}
+
+static u64 mem_cgroup_min_usage_read(struct cgroup *cg, struct cftype *cft)
+{
+	struct mem_cgroup *mem = mem_cgroup_from_cont(cg);
+
+	return mem->min_usage;
+}
+
 static struct cftype mem_cgroup_files[] = {
 	{
 		.name = "usage_in_bytes",
@@ -1036,8 +1059,43 @@ static struct cftype mem_cgroup_files[] = {
 		.name = "stat",
 		.read_map = mem_control_stat_show,
 	},
+	{
+		.name = "min_usage_in_bytes",
+		.write_string = mem_cgroup_min_usage_write,
+		.read_u64 = mem_cgroup_min_usage_read,
+	},
 };
 
+int mem_cgroup_canreclaim(struct page *page, struct mem_cgroup *mem1)
+{
+	struct page_cgroup *pc;
+	int result = 1;
+
+	if (mem1 != NULL)
+		return 1;
+
+	lock_page_cgroup(page);
+	pc = page_get_page_cgroup(page);
+	if (pc) {
+		struct mem_cgroup *mem2 = pc->mem_cgroup;
+		unsigned long long min_usage;
+
+		BUG_ON(mem2 == NULL);
+		min_usage = mem2->min_usage;
+		if (min_usage != 0) {
+			unsigned long flags;
+
+			spin_lock_irqsave(&mem2->res.lock, flags);
+			if (mem2->res.usage <= min_usage)
+				result = 0;
+			spin_unlock_irqrestore(&mem2->res.lock, flags);
+		}
+	}
+	unlock_page_cgroup(page);
+
+	return result;
+}
+
 static int alloc_mem_cgroup_per_zone_info(struct mem_cgroup *mem, int node)
 {
 	struct mem_cgroup_per_node *pn;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 33e4319..ef37968 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -673,6 +673,9 @@ static unsigned long shrink_page_list(struct list_head *page_list,
 					referenced && page_mapping_inuse(page))
 			goto activate_locked;
 
+		if (!mem_cgroup_canreclaim(page, sc->mem_cgroup))
+			goto activate_locked;
+
 #ifdef CONFIG_SWAP
 		/*
 		 * Anonymous process memory has backing store?
@@ -1294,7 +1297,9 @@ static void shrink_active_list(unsigned long nr_pages, struct zone *zone,
 			continue;
 		}
 
-		if (page_referenced(page, 0, sc->mem_cgroup)) {
+		if (!mem_cgroup_canreclaim(page, sc->mem_cgroup)) {
+			list_add(&page->lru, &l_active);
+		} else if (page_referenced(page, 0, sc->mem_cgroup)) {
 			pgmoved++;
 			if (file) {
 				/* Referenced file pages stay active. */

--
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][RFC] memory.min_usage again

[KOSAKI Motohiro]

Hi

>> here's a patch to implement memory.min_usage,
>> which controls the minimum memory usage for a cgroup.
>>
>> it works similarly to mlock;
>> global memory reclamation doesn't reclaim memory from
>> cgroups whose memory usage is below the value.
>> setting it too high is a dangerous operation.
>>
>> it's against 2.6.24-rc3-mm2 + memory.swappiness patch i posted here yesterday.
>> but it's logically independent from the swappiness patch.
>>
>> todo:
>> - restrict non-root user's operation ragardless of owner of cgroupfs files?
>> - make oom killer aware of this?

This is  really no good patch description.
You should write
 - Why you think it is useful.
 - Who need it.

A reviewer oftern want check to match coder's intention and actual code.

--
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][RFC] memory.min_usage again

[Balbir Singh]

YAMAMOTO Takashi wrote:
> hi,
> 
>> hi,
>>
>> here's a patch to implement memory.min_usage,
>> which controls the minimum memory usage for a cgroup.
>>
>> it works similarly to mlock;
>> global memory reclamation doesn't reclaim memory from
>> cgroups whose memory usage is below the value.
>> setting it too high is a dangerous operation.
>>

Looking through the code I am a little worried, what if every cgroup is below
minimum value and the system is under memory pressure, do we OOM, while we could
have easily reclaimed?

I would prefer to see some heuristics around such a feature, mostly around the
priority that do_try_to_free_pages() to determine how desperate we are for
reclaiming memory.

-- 
	Balbir

--
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][RFC] memory.min_usage again

[KAMEZAWA Hiroyuki]

On Wed, 10 Sep 2008 08:32:15 -0700
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> YAMAMOTO Takashi wrote:
> > hi,
> > 
> >> hi,
> >>
> >> here's a patch to implement memory.min_usage,
> >> which controls the minimum memory usage for a cgroup.
> >>
> >> it works similarly to mlock;
> >> global memory reclamation doesn't reclaim memory from
> >> cgroups whose memory usage is below the value.
> >> setting it too high is a dangerous operation.
> >>
> 
> Looking through the code I am a little worried, what if every cgroup is below
> minimum value and the system is under memory pressure, do we OOM, while we could
> have easily reclaimed?
> 
> I would prefer to see some heuristics around such a feature, mostly around the
> priority that do_try_to_free_pages() to determine how desperate we are for
> reclaiming memory.
> 
Taking "priority" of memory reclaim path into account is good.

==
static unsigned long shrink_inactive_list(unsigned long max_scan,
                        struct zone *zone, struct scan_control *sc,
                        int priority, int file)
==
How about ignore min_usage if "priority < DEF_PRIORITY - 2" ?


Thanks,
-Kame

--
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][RFC] memory.min_usage again

[YAMAMOTO Takashi]

hi,

> On Wed, 10 Sep 2008 08:32:15 -0700
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > YAMAMOTO Takashi wrote:
> > > hi,
> > > 
> > >> hi,
> > >>
> > >> here's a patch to implement memory.min_usage,
> > >> which controls the minimum memory usage for a cgroup.
> > >>
> > >> it works similarly to mlock;
> > >> global memory reclamation doesn't reclaim memory from
> > >> cgroups whose memory usage is below the value.
> > >> setting it too high is a dangerous operation.
> > >>
> > 
> > Looking through the code I am a little worried, what if every cgroup is below
> > minimum value and the system is under memory pressure, do we OOM, while we could
> > have easily reclaimed?

i'm not sure what you are worring about.  can you explain a little more?
under the configuration, OOM is an expected behaviour.

> > 
> > I would prefer to see some heuristics around such a feature, mostly around the
> > priority that do_try_to_free_pages() to determine how desperate we are for
> > reclaiming memory.
> > 
> Taking "priority" of memory reclaim path into account is good.
> 
> ==
> static unsigned long shrink_inactive_list(unsigned long max_scan,
>                         struct zone *zone, struct scan_control *sc,
>                         int priority, int file)
> ==
> How about ignore min_usage if "priority < DEF_PRIORITY - 2" ?

are you suggesting ignoring mlock etc as well in that case?

YAMAMOTO Takashi

> 
> 
> Thanks,
> -Kame
> 
> --
> 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][RFC] memory.min_usage again

[Balbir Singh]

YAMAMOTO Takashi wrote:
> hi,
> 
>> On Wed, 10 Sep 2008 08:32:15 -0700
>> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>>
>>> YAMAMOTO Takashi wrote:
>>>> hi,
>>>>
>>>>> hi,
>>>>>
>>>>> here's a patch to implement memory.min_usage,
>>>>> which controls the minimum memory usage for a cgroup.
>>>>>
>>>>> it works similarly to mlock;
>>>>> global memory reclamation doesn't reclaim memory from
>>>>> cgroups whose memory usage is below the value.
>>>>> setting it too high is a dangerous operation.
>>>>>
>>> Looking through the code I am a little worried, what if every cgroup is below
>>> minimum value and the system is under memory pressure, do we OOM, while we could
>>> have easily reclaimed?
> 
> i'm not sure what you are worring about.  can you explain a little more?
> under the configuration, OOM is an expected behaviour.
> 

Yes, but an OOM will violate the min_memory right? We promise not to reclaim,
but we can OOM. I would rather implement them as watermarks (best effort
service, rather than a guarantee). OOMing the system sounds bad, specially if
memory can be reclaimed.. No?

>>> I would prefer to see some heuristics around such a feature, mostly around the
>>> priority that do_try_to_free_pages() to determine how desperate we are for
>>> reclaiming memory.
>>>
>> Taking "priority" of memory reclaim path into account is good.
>>
>> ==
>> static unsigned long shrink_inactive_list(unsigned long max_scan,
>>                         struct zone *zone, struct scan_control *sc,
>>                         int priority, int file)
>> ==
>> How about ignore min_usage if "priority < DEF_PRIORITY - 2" ?
> 
> are you suggesting ignoring mlock etc as well in that case?
>

No.. not at all, we will get an mlock controller as well.


> YAMAMOTO Takashi
> 


-- 
	Balbir

--
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][RFC] memory.min_usage again

[KAMEZAWA Hiroyuki]

On Mon, 29 Sep 2008 09:43:32 +0900 (JST)
yamamoto@valinux.co.jp (YAMAMOTO Takashi) wrote:
> > > 
> > > I would prefer to see some heuristics around such a feature, mostly around the
> > > priority that do_try_to_free_pages() to determine how desperate we are for
> > > reclaiming memory.
> > > 
> > Taking "priority" of memory reclaim path into account is good.
> > 
> > ==
> > static unsigned long shrink_inactive_list(unsigned long max_scan,
> >                         struct zone *zone, struct scan_control *sc,
> >                         int priority, int file)
> > ==
> > How about ignore min_usage if "priority < DEF_PRIORITY - 2" ?
> 
> are you suggesting ignoring mlock etc as well in that case?
> 

No. Just freeing pages, which are usually freed is good.

==
int mem_cgroup_canreclaim(struct page *page, struct mem_cgroup *mem1,
			  int priority)
{
	struct page_cgroup *pc;
	int result = 1;

	if (mem1 != NULL)
		return 1;
	/* global lru is busy ? */
        if (priority < DEF_PEIORITY - 1)
		return 1;
        ....
}
==
Maybe min_usage can works as *soft* mlock by this.

Or another idea.
Making memory.min_usage as memory.reclaim_priority_level and allows

  priority_level == 0 => can_reclaim() returns 1 always.
  priority_level == 1 => can_reclaim returns 1 if priority < DEF_PRIORITY-1.
  priority_level == 2 => can_reclaim returns 1 if priority < DEF_PRIORITY-2.

(and only 0,1,2 are allowed.)

setting min_usage will not be prefered by lru management people.
This can work as "advice" to global lru.

Hmm ?

Thanks,
-Kame

--
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>