Re: [RFC] CMA page migration failure due to buffers on bh_lru

From: Gioh Kim
Date: Mon Jun 30 2014 - 21:07:15 EST


Hi,Laura.

I have a question.

Does the __evict_bh_lru() not need bh_lru_lock()?
The get_cpu_var() has already preenpt_disable() and can prevent other thread.
But get_cpu_var cannot prevent IRQ context such like page-fault.
I think if a page-fault occured and a file is read in IRQ context it can change cpu-lru.

Is my concern correct?


2014-06-30 ìì 4:49, Laura Abbott ì ê:
(cc-ing Hugh since he had comments on the patch before)

On 6/26/2014 4:23 PM, Gioh Kim wrote:


2014-06-27 ìì 12:57, Michal Nazarewicz ì ê:
On Tue, Jun 24 2014, Gioh Kim <gioh.kim@xxxxxxx> wrote:
Hello,

I am trying to apply CMA feature for my platform.
My kernel version, 3.10.x, is not allocating memory from CMA area so that I applied
a Joonsoo Kim's patch (https://lkml.org/lkml/2014/5/28/64).
Now my platform can use CMA area effectively.

But I have many failures to allocate memory from CMA area.
I found the same situation to Laura Abbott's patch descrbing,
https://lkml.org/lkml/2012/8/31/313,
that releases buffer-heads attached at CPU's LRU list.

If Joonsoo's patch is applied and/or CMA feature is applied more and more,
buffer-heads problem is going to be serious definitely.

Please look into the Laura's patch again.
I think it must be applied with Joonsoo's patch.

Just to make sure I understood you correctly, you're saying Laura's
patch at <https://lkml.org/lkml/2012/8/31/313> fixes your issue?


Yes, it is.

I submitted this before and it was suggested that this was more
related to filesystems

http://marc.info/?l=linaro-mm-sig&m=137645770708817&w=2

I never saw more discussion and pushed this into the 'CMA hacks' pile.
So far we've been keeping the patch out of tree and it's useful to know
that others have found the same problem. I'm willing to resubmit the
patch for further discussion.

Thanks,
Laura

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