Re: [RFC][PATCH] Clarify mem_cgroup lock handling and avoid races.

[Balbir Singh <balbir@linux.vnet.ibm.com>]

Hirokazu Takahashi wrote:
> Hi,
> 
>>>> We thought of this as well. We dropped it, because we need to track only user
>>>> pages at the moment. Doing it for all pages means having the overhead for each
>>>> page on the system.
>>> Let me clarify that the overhead you said is you'll waste some memory
>>> whose pages are assigned for the kernel internal use, right?
>>> If so, it wouldn't be a big problem since most of the pages are assigned to
>>> process anonymous memory or to the page cache as Paul said.
>>>
>> My idea is..
>> (1) It will be big waste of memory to pre-allocate all page_cgroup struct at
>>     boot.  Because following two will not need it.
>>     (1) kernel memory
>>     (2) HugeTLB memory
>> Mainly because of (2), I don't like pre-allocation.
> 
> I thought kernel memory wasn't big deal but I didn't think about HugeTLB memory.
> 

Yes, true. I don't like pre-allocation either, but people have complained about
increase in page size. I am not committing to pre-allocation, but I promised I
would look at bringing the overhead down. Nick suggested using a radix tree.

>> But we'll be able to archive  pfn <-> page_cgroup relationship using
>> on-demand memmap style.
>> (Someone mentioned about using radix-tree in other thread.)
> 
> My concern is this approach seems to require some spinlocks to protect the
> radix-tree. If you really don't want to allocate page_cgroups for HugeTLB
> memory, what do you think if you should turn on the memory controller after
> allocating HugeTlb pages?
> 

Yes, I expressed that concern on IRC as well. We've have to measure and see
performance impact. It was told to me from experience that, the overhead would
be lost as noise (which I find hard to believe).

>> Balbir-san, I'd like to do some work aroung this becasue I've experience
>> sparsemem and memory hotplug developments.
>>
>> Or have you already started ?
> 
> Not yet. So you can go ahead.
> 

Yes, please feel free to do so.

>> Thanks,
>> -Kame
> 
> Thank you,
> Hirokazu Takahashi.
> 
> --
> 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>


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

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