From: Andrea Arcangeli <aarcange@redhat.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Mel Gorman <mel@csn.ul.ie>,
Andrew Morton <akpm@linux-foundation.org>,
Arthur Marsh <arthur.marsh@internode.on.net>,
Clemens Ladisch <cladisch@googlemail.com>,
Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] mm: compaction: Minimise the time IRQs are disabled while isolating pages for migration
Date: Tue, 1 Mar 2011 17:19:00 +0100 [thread overview]
Message-ID: <20110301161900.GA21860@random.random> (raw)
In-Reply-To: <20110301153558.GA2031@barrios-desktop>
On Wed, Mar 02, 2011 at 12:35:58AM +0900, Minchan Kim wrote:
> On Tue, Mar 01, 2011 at 01:49:25PM +0900, KAMEZAWA Hiroyuki wrote:
> > On Tue, 1 Mar 2011 13:11:46 +0900
> > Minchan Kim <minchan.kim@gmail.com> wrote:
> >
> > > On Tue, Mar 01, 2011 at 08:42:09AM +0900, KAMEZAWA Hiroyuki wrote:
> > > > On Mon, 28 Feb 2011 10:18:27 +0000
> > > > Mel Gorman <mel@csn.ul.ie> wrote:
> > > >
> > > > > > BTW, can't we drop disable_irq() from all lru_lock related codes ?
> > > > > >
> > > > >
> > > > > I don't think so - at least not right now. Some LRU operations such as LRU
> > > > > pagevec draining are run from IPI which is running from an interrupt so
> > > > > minimally spin_lock_irq is necessary.
> > > > >
> > > >
> > > > pagevec draining is done by workqueue(schedule_on_each_cpu()).
> > > > I think only racy case is just lru rotation after writeback.
> > >
> > > put_page still need irq disable.
> > >
> >
> > Aha..ok. put_page() removes a page from LRU via __page_cache_release().
> > Then, we may need to remove a page from LRU under irq context.
> > Hmm...
>
> But as __page_cache_release's comment said, normally vm doesn't release page in
> irq context. so it would be rare.
> If we can remove it, could we change all of spin_lock_irqsave with spin_lock?
> If it is right, I think it's very desirable to reduce irq latency.
>
> How about this? It's totally a quick implementation and untested.
> I just want to hear opinions of you guys if the work is valuable or not before
> going ahead.
pages freed from irq shouldn't be PageLRU.
deferring freeing to workqueue doesn't look ok. firewall loads runs
only from irq and this will cause some more work and a delay in the
freeing. I doubt it's worhwhile especially for the lru_lock.
WARNING: multiple messages have this Message-ID (diff)
From: Andrea Arcangeli <aarcange@redhat.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Mel Gorman <mel@csn.ul.ie>,
Andrew Morton <akpm@linux-foundation.org>,
Arthur Marsh <arthur.marsh@internode.on.net>,
Clemens Ladisch <cladisch@googlemail.com>,
Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] mm: compaction: Minimise the time IRQs are disabled while isolating pages for migration
Date: Tue, 1 Mar 2011 17:19:00 +0100 [thread overview]
Message-ID: <20110301161900.GA21860@random.random> (raw)
In-Reply-To: <20110301153558.GA2031@barrios-desktop>
On Wed, Mar 02, 2011 at 12:35:58AM +0900, Minchan Kim wrote:
> On Tue, Mar 01, 2011 at 01:49:25PM +0900, KAMEZAWA Hiroyuki wrote:
> > On Tue, 1 Mar 2011 13:11:46 +0900
> > Minchan Kim <minchan.kim@gmail.com> wrote:
> >
> > > On Tue, Mar 01, 2011 at 08:42:09AM +0900, KAMEZAWA Hiroyuki wrote:
> > > > On Mon, 28 Feb 2011 10:18:27 +0000
> > > > Mel Gorman <mel@csn.ul.ie> wrote:
> > > >
> > > > > > BTW, can't we drop disable_irq() from all lru_lock related codes ?
> > > > > >
> > > > >
> > > > > I don't think so - at least not right now. Some LRU operations such as LRU
> > > > > pagevec draining are run from IPI which is running from an interrupt so
> > > > > minimally spin_lock_irq is necessary.
> > > > >
> > > >
> > > > pagevec draining is done by workqueue(schedule_on_each_cpu()).
> > > > I think only racy case is just lru rotation after writeback.
> > >
> > > put_page still need irq disable.
> > >
> >
> > Aha..ok. put_page() removes a page from LRU via __page_cache_release().
> > Then, we may need to remove a page from LRU under irq context.
> > Hmm...
>
> But as __page_cache_release's comment said, normally vm doesn't release page in
> irq context. so it would be rare.
> If we can remove it, could we change all of spin_lock_irqsave with spin_lock?
> If it is right, I think it's very desirable to reduce irq latency.
>
> How about this? It's totally a quick implementation and untested.
> I just want to hear opinions of you guys if the work is valuable or not before
> going ahead.
pages freed from irq shouldn't be PageLRU.
deferring freeing to workqueue doesn't look ok. firewall loads runs
only from irq and this will cause some more work and a delay in the
freeing. I doubt it's worhwhile especially for the lru_lock.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-03-01 16:20 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-01 15:35 [PATCH 2/2] mm: compaction: Minimise the time IRQs are disabled while isolating pages for migration Minchan Kim
2011-03-01 15:35 ` Minchan Kim
2011-03-01 16:19 ` Andrea Arcangeli [this message]
2011-03-01 16:19 ` Andrea Arcangeli
2011-03-01 22:22 ` Minchan Kim
2011-03-01 22:22 ` Minchan Kim
2011-03-01 22:34 ` Andrew Morton
2011-03-01 22:34 ` Andrew Morton
2011-03-01 22:57 ` Minchan Kim
2011-03-01 22:57 ` Minchan Kim
-- strict thread matches above, loose matches on Subject: below --
2011-02-25 20:04 [PATCH 0/2] Reduce the amount of time compaction disables IRQs for V2 Mel Gorman
2011-02-25 20:04 ` [PATCH 2/2] mm: compaction: Minimise the time IRQs are disabled while isolating pages for migration Mel Gorman
2011-02-25 20:04 ` Mel Gorman
2011-02-25 22:32 ` Johannes Weiner
2011-02-25 22:32 ` Johannes Weiner
2011-02-26 0:16 ` Andrea Arcangeli
2011-02-26 0:16 ` Andrea Arcangeli
2011-02-28 2:17 ` KAMEZAWA Hiroyuki
2011-02-28 2:17 ` KAMEZAWA Hiroyuki
2011-02-28 5:48 ` Andrea Arcangeli
2011-02-28 5:48 ` Andrea Arcangeli
2011-02-28 5:54 ` KAMEZAWA Hiroyuki
2011-02-28 5:54 ` KAMEZAWA Hiroyuki
2011-02-28 9:28 ` Mel Gorman
2011-02-28 9:28 ` Mel Gorman
2011-02-28 9:42 ` KAMEZAWA Hiroyuki
2011-02-28 9:42 ` KAMEZAWA Hiroyuki
2011-02-28 10:18 ` Mel Gorman
2011-02-28 10:18 ` Mel Gorman
2011-02-28 23:42 ` KAMEZAWA Hiroyuki
2011-02-28 23:42 ` KAMEZAWA Hiroyuki
2011-03-01 4:11 ` Minchan Kim
2011-03-01 4:11 ` Minchan Kim
2011-03-01 4:49 ` KAMEZAWA Hiroyuki
2011-03-01 4:49 ` KAMEZAWA Hiroyuki
2011-02-28 23:01 ` Minchan Kim
2011-02-28 23:01 ` Minchan Kim
2011-02-28 23:07 ` Andrea Arcangeli
2011-02-28 23:07 ` Andrea Arcangeli
2011-02-28 23:25 ` Minchan Kim
2011-02-28 23:25 ` Minchan Kim
2011-03-01 22:15 ` Andrew Morton
2011-03-01 22:15 ` Andrew Morton
2011-02-25 18:00 [PATCH 0/2] Reduce the amount of time compaction disables IRQs for Mel Gorman
2011-02-25 18:00 ` [PATCH 2/2] mm: compaction: Minimise the time IRQs are disabled while isolating pages for migration Mel Gorman
2011-02-25 18:00 ` 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=20110301161900.GA21860@random.random \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arthur.marsh@internode.on.net \
--cc=cladisch@googlemail.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@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.