From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Huang Shijie <shijie8@gmail.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"mel@csn.ul.ie" <mel@csn.ul.ie>,
"kosaki.motohiro@jp.fujitsu.com" <kosaki.motohiro@jp.fujitsu.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH 4/4] mm/page_alloc : relieve zone->lock's pressure for memory free
Date: Tue, 12 Jan 2010 12:21:16 +0800 [thread overview]
Message-ID: <20100112042116.GA26035@localhost> (raw)
In-Reply-To: <28c262361001112005s745e5ecj9fd6ae3d0d997477@mail.gmail.com>
On Tue, Jan 12, 2010 at 12:05:32PM +0800, Minchan Kim wrote:
> On Tue, Jan 12, 2010 at 11:27 AM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > On Tue, Jan 12, 2010 at 09:47:08AM +0900, KAMEZAWA Hiroyuki wrote:
> >> > Thanks, Huang.
> >> >
> >> > Frankly speaking, I am not sure this ir right way.
> >> > This patch is adding to fine-grained locking overhead
> >> >
> >> > As you know, this functions are one of hot pathes.
> >> > In addition, we didn't see the any problem, until now.
> >> > It means out of synchronization in ZONE_ALL_UNRECLAIMABLE
> >> > and pages_scanned are all right?
> >> >
> >> > If it is, we can move them out of zone->lock, too.
> >> > If it isn't, we need one more lock, then.
> >> >
> >> I don't want to see additional spin_lock, here.
> >>
> >> About ZONE_ALL_UNRECLAIMABLE, it's not necessary to be handled in atomic way.
> >> If you have concerns with other flags, please modify this with single word,
> >> instead of a bit field.
> >
> > I'd second it. It's not a big problem to reset ZONE_ALL_UNRECLAIMABLE
> > and pages_scanned outside of zone->lru_lock.
> >
> > Clear of ZONE_ALL_UNRECLAIMABLE is already atomic; if we lose one
>
> I'd second it? What's meaning? I can't understand your point since I am not
> english native.
=> "I agree with Kame." :)
> BTW,
> Hmm. It's not atomic as Kame pointed out.
>
> Now, zone->flags have several bit.
> * ZONE_ALL_UNRECLAIMALBE
> * ZONE_RECLAIM_LOCKED
> * ZONE_OOM_LOCKED.
>
> I think this flags are likely to race when the memory pressure is high.
> If we don't prevent race, concurrent reclaim and killing could be happened.
> So I think reset zone->flags outside of zone->lock would make our efforts which
> prevent current reclaim and killing invalidate.
zone_set_flag()/zone_clear_flag() calls set_bit()/clear_bit() which is
atomic. Do you mean more high level exclusion?
Thanks,
Fengguang
--
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>
next prev parent reply other threads:[~2010-01-12 4:21 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-11 4:37 [PATCH 1/4] mm/page_alloc : rename rmqueue_bulk to rmqueue_single Huang Shijie
2010-01-11 4:37 ` [PATCH 2/4] mm/page_alloc : relieve the zone->lock's pressure for allocation Huang Shijie
2010-01-11 4:37 ` [PATCH 3/4] mm/page_alloc : modify the return type of __free_one_page Huang Shijie
2010-01-11 4:37 ` [PATCH 4/4] mm/page_alloc : relieve zone->lock's pressure for memory free Huang Shijie
2010-01-11 5:20 ` Minchan Kim
2010-01-11 6:01 ` Huang Shijie
2010-01-11 6:27 ` Huang Shijie
2010-01-11 6:38 ` Minchan Kim
2010-01-11 6:59 ` Huang Shijie
2010-01-12 0:47 ` KAMEZAWA Hiroyuki
2010-01-12 2:02 ` Huang Shijie
2010-01-12 2:07 ` KAMEZAWA Hiroyuki
2010-01-12 2:32 ` Huang Shijie
2010-01-12 2:27 ` Wu Fengguang
2010-01-12 2:56 ` KOSAKI Motohiro
2010-01-12 3:02 ` Huang Shijie
2010-01-12 4:05 ` Minchan Kim
2010-01-12 4:21 ` Wu Fengguang [this message]
2010-01-12 4:32 ` KAMEZAWA Hiroyuki
2010-01-12 4:59 ` Wu Fengguang
2010-01-12 5:09 ` Wu Fengguang
2010-01-12 5:10 ` KOSAKI Motohiro
2010-01-12 7:36 ` David Rientjes
2010-01-12 8:56 ` KOSAKI Motohiro
2010-01-12 21:39 ` David Rientjes
2010-01-13 0:01 ` KOSAKI Motohiro
2010-01-12 4:48 ` Minchan Kim
2010-01-12 2:51 ` Huang Shijie
2010-01-12 3:03 ` Wu Fengguang
2010-01-12 3:05 ` KOSAKI Motohiro
2010-01-11 5:04 ` [PATCH 3/4] mm/page_alloc : modify the return type of __free_one_page Minchan Kim
2010-01-12 2:56 ` KOSAKI Motohiro
2010-01-18 11:25 ` Mel Gorman
2010-01-19 1:49 ` Huang Shijie
2010-01-11 5:02 ` [PATCH 2/4] mm/page_alloc : relieve the zone->lock's pressure for allocation Minchan Kim
2010-01-11 5:13 ` Huang Shijie
2010-01-12 2:54 ` KOSAKI Motohiro
2010-01-18 11:24 ` Mel Gorman
2010-01-11 5:00 ` [PATCH 1/4] mm/page_alloc : rename rmqueue_bulk to rmqueue_single Minchan Kim
2010-01-12 2:52 ` KOSAKI Motohiro
2010-01-18 11:21 ` Mel Gorman
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=20100112042116.GA26035@localhost \
--to=fengguang.wu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=riel@redhat.com \
--cc=shijie8@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).