Re: [PATCH 1/3] slqb: Do not use DEFINE_PER_CPU for per-node data

From: Mel Gorman
Date: Mon Sep 21 2009 - 05:09:27 EST


On Mon, Sep 21, 2009 at 02:32:33PM +0530, Sachin Sant wrote:
> Mel Gorman wrote:
>>> I applied the three patches from Mel and one from Tejun.
>>>
>>
>> Thanks Sachin
>>
>> Was there any useful result from Tejun's patch applied on its own?
>>
> Haven't tried with just the patch from Tejun. I will give this a try.
> I might not get a chance to test this until late in the evening my time.
> (Today being a holiday for me )
>

Ok, I've blatently nabbed your machine again then (yoink haha) and
a relevant kernel is building at the moment. I'll put the dmesg when it
becomes available. Go enjoy your holiday

>>> Tejun, the above hang looks exactly the same as the one
>>> i have reported here :
>>>
>>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-September/075791.html
>>>
>>> This particular hang was bisected to the following patch
>>>
>>> powerpc64: convert to dynamic percpu allocator
>>>
>>> This hang can be recreated without SLQB. So i think this is a different
>>> problem.
>>>
>>>
>>
>> Was that bug ever resolved?
>>
> The bug was still present with git9(78f28b..). With latest git
> git10(ebc79c4 ..)i haven't tested it yet because of perf counter
> build errors.
>

Ok, so right now there are three separate bugs with this machine

1. SLQB + Memoryless shots itself in the face due to suspected
per-cpu area corruption
2. SLQB with memoryless nodes frees pages remotely and allocates
locally with a similar effect as if it was a memory leak.
3. pcpu_alloc can hang but is not related to SLQB

Thanks

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/