From: Gioh Kim <gioh.kim@lge.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Laura Abbott <lauraa@codeaurora.org>
Cc: "Michal Nazarewicz" <mina86@mina86.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Joonsoo Kim" <iamjoonsoo.kim@lge.com>,
"Mel Gorman" <mgorman@suse.de>, 이건호 <gunho.lee@lge.com>,
"Hugh Dickins" <hughd@google.com>
Subject: Re: [RFC] CMA page migration failure due to buffers on bh_lru
Date: Thu, 03 Jul 2014 16:34:41 +0900 [thread overview]
Message-ID: <53B50791.50208@lge.com> (raw)
In-Reply-To: <20140701224621.bb6a5157.akpm@linux-foundation.org>
Hi, Laura,
I has replaced the evict_bh_lrus(bh) with invalidate_bh_lrus() and it is working fine.
How about submit new patch with invalidate_bh_lrus()?
I would appreciate it.
2014-07-02 i??i?? 2:46, Andrew Morton i?' e,?:
> On Mon, 30 Jun 2014 19:02:45 -0700 Laura Abbott <lauraa@codeaurora.org> wrote:
>
>> On 6/30/2014 6:07 PM, Gioh Kim wrote:
>>> 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?
>>>
>>>
>>
>> __evict_bh_lru is called via on_each_cpu_cond which I believe will disable irqs.
>> I based the code on the existing invalidate_bh_lru which did not take the bh_lru_lock
>> either. It's possible I missed something though.
>
> I fear that running on_each_cpu() within try_to_free_buffers() is going
> to be horridly expensive in some cases.
>
> Maybe CMA can use invalidate_bh_lrus() to shoot down everything before
> trying the allocation attempt. That should increase the success rate
> greatly and doesn't burden page reclaim. The bh LRU isn't terribly
> important from a performance point of view, so emptying it occasionally
> won't hurt.
>
>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Gioh Kim <gioh.kim@lge.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Laura Abbott <lauraa@codeaurora.org>
Cc: "Michal Nazarewicz" <mina86@mina86.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Joonsoo Kim" <iamjoonsoo.kim@lge.com>,
"Mel Gorman" <mgorman@suse.de>, 이건호 <gunho.lee@lge.com>,
"Hugh Dickins" <hughd@google.com>
Subject: Re: [RFC] CMA page migration failure due to buffers on bh_lru
Date: Thu, 03 Jul 2014 16:34:41 +0900 [thread overview]
Message-ID: <53B50791.50208@lge.com> (raw)
In-Reply-To: <20140701224621.bb6a5157.akpm@linux-foundation.org>
Hi, Laura,
I has replaced the evict_bh_lrus(bh) with invalidate_bh_lrus() and it is working fine.
How about submit new patch with invalidate_bh_lrus()?
I would appreciate it.
2014-07-02 오후 2:46, Andrew Morton 쓴 글:
> On Mon, 30 Jun 2014 19:02:45 -0700 Laura Abbott <lauraa@codeaurora.org> wrote:
>
>> On 6/30/2014 6:07 PM, Gioh Kim wrote:
>>> 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?
>>>
>>>
>>
>> __evict_bh_lru is called via on_each_cpu_cond which I believe will disable irqs.
>> I based the code on the existing invalidate_bh_lru which did not take the bh_lru_lock
>> either. It's possible I missed something though.
>
> I fear that running on_each_cpu() within try_to_free_buffers() is going
> to be horridly expensive in some cases.
>
> Maybe CMA can use invalidate_bh_lrus() to shoot down everything before
> trying the allocation attempt. That should increase the success rate
> greatly and doesn't burden page reclaim. The bh LRU isn't terribly
> important from a performance point of view, so emptying it occasionally
> won't hurt.
>
>
next prev parent reply other threads:[~2014-07-03 7:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 1:12 [RFC] CMA page migration failure due to buffers on bh_lru Gioh Kim
2014-06-24 1:12 ` Gioh Kim
2014-06-26 15:57 ` Michal Nazarewicz
2014-06-26 15:57 ` Michal Nazarewicz
2014-06-26 23:23 ` Gioh Kim
2014-06-26 23:23 ` Gioh Kim
2014-06-29 19:49 ` Laura Abbott
2014-06-29 19:49 ` Laura Abbott
2014-07-01 1:07 ` Gioh Kim
2014-07-01 1:07 ` Gioh Kim
2014-07-01 2:02 ` Laura Abbott
2014-07-01 2:02 ` Laura Abbott
2014-07-02 5:46 ` Andrew Morton
2014-07-02 5:46 ` Andrew Morton
2014-07-03 7:34 ` Gioh Kim [this message]
2014-07-03 7:34 ` Gioh Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B50791.50208@lge.com \
--to=gioh.kim@lge.com \
--cc=akpm@linux-foundation.org \
--cc=gunho.lee@lge.com \
--cc=hughd@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=lauraa@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mgorman@suse.de \
--cc=mina86@mina86.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.