Re: CMA and zone watermarks

[Marek Szyprowski <m.szyprowski@samsung.com>]

Hello,

On 10/9/2012 7:07 AM, Minchan Kim wrote:
> On Tue, Oct 09, 2012 at 06:53:29AM +0200, Marek Szyprowski wrote:
>> Hello,
>>
>> On 10/9/2012 6:43 AM, Minchan Kim wrote:
>>> On Tue, Oct 09, 2012 at 05:12:21AM +0200, Marek Szyprowski wrote:
>>>> On 10/9/2012 5:10 AM, Minchan Kim wrote:
>>>>> On Mon, Oct 08, 2012 at 05:41:14PM +0200, Rabin Vincent wrote:
>>
>>>>> Fortunately, recently, Bart sent a patch about that.
>>>>> http://marc.info/?l=linux-mm&m=134763299016693&w=2
>>>>>
>>>>> Could you test above patches in your kernel?
>>>>> You have to apply [2/4], [3/4], [4/4] and don't need [1/4].
>>>>
>>>> AFAIR without patch [1/4], free cma page counter will go below zero
>>>> and weird thing will happen, so better apply the complete patchset.
>>>
>>> I can't understand your point. [1/4] is just fix for correcting trace
>>> No?
>>
>> I just remember we ran into such strange negative number of free cma
>> pages issue without that patch, but maybe the final patchset will
>> simply fail to apply without the first patch.
>
> I have no objection to apply them all, of course.
> But note that if you suffer from such strange bug without [1/4],
> it should be dug in without buring into just "fixing of the trace"
> comment. As I saw the code without [1/4], I can't find any fault.
> Could you elaborate it more if you have any guessing in mind?

I remember that in one version of the Bartek's patches, 
page_private(page) has been used directly for getting the migratetype 
after a call to __free_one_page() (the same way as 
trace_mm_page_pcpu_drain() used it), what resulted in incorrect counting 
of free pages. The issue has been fixed then by the patch [1/4].

Now I've check that the next patches use mt variable instead of 
page_private(page), so they will simply not apply without [1/4]. No 
other issues should be expected. I'm sorry for confusion.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center