All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laura Abbott <lauraa@codeaurora.org>
To: Gioh Kim <gioh.kim@lge.com>,
	Michal Nazarewicz <mina86@mina86.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: "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: Mon, 30 Jun 2014 19:02:45 -0700	[thread overview]
Message-ID: <53B216C5.8020503@codeaurora.org> (raw)
In-Reply-To: <53B209BA.8010106@lge.com>

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.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
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: Laura Abbott <lauraa@codeaurora.org>
To: Gioh Kim <gioh.kim@lge.com>,
	Michal Nazarewicz <mina86@mina86.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: "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: Mon, 30 Jun 2014 19:02:45 -0700	[thread overview]
Message-ID: <53B216C5.8020503@codeaurora.org> (raw)
In-Reply-To: <53B209BA.8010106@lge.com>

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.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-07-01  2:02 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 [this message]
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
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=53B216C5.8020503@codeaurora.org \
    --to=lauraa@codeaurora.org \
    --cc=gioh.kim@lge.com \
    --cc=gunho.lee@lge.com \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --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.