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