On Wed, 27 Aug 2008 06:47:59 +0530
Balbir Singh [off-list ref] wrote:

KAMEZAWA Hiroyuki wrote:

quoted

On Tue, 26 Aug 2008 17:16:20 +0530
Balbir Singh [off-list ref] wrote:

quoted

quoted

+/*
+ * per-cpu slot for freeing page_cgroup in lazy manner.
+ * All page_cgroup linked to this list is OBSOLETE.
+ */
+struct mem_cgroup_sink_list {
+	int count;
+	struct page_cgroup *next;
+};

Can't we reuse the lru field in page_cgroup to build a list? Do we need them on
the memory controller LRU if they are obsolete? I want to do something similar
for both additions and deletions - reuse pagevec style, basically. I am OK,
having a list as well, in that case we can just reuse the LRU pointer.

reusing page_cgroup->lru is not a choice because this patch is for avoid
locking on mz->lru_lock (and kfree).
But using vector can be a choice. I'll try in the next version.

Kame,

Do we need to use the lru_lock? If we do an atomic check on PcgObsolete(), can't
we use another lock for obsolete pages and still use the lru list head?

To reuse that, we'll have to modify lru.prev or lru.next pointer. 

And there will be race with 
 - move_list,
 - isolate_pages,
 - (new) force_empty

move_list and (new)force_empty modifies lru.prev/lru.next.
So, I think it's dangerous at this stage. (We can revist this when it's
necessary (if vector seems bad.)
Anyway, I think I'll be able to remove page_cgroup->next pointer I added.

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>