From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Hugh Dickins <hughd@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
Dave Jones <davej@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Cong Wang <amwang@redhat.com>,
Markus Trippelsdorf <markus@trippelsdorf.de>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kosaki.motohiro@gmail.com
Subject: Re: WARNING: at mm/page-writeback.c:1990 __set_page_dirty_nobuffers+0x13a/0x170()
Date: Mon, 04 Jun 2012 00:21:34 -0400 [thread overview]
Message-ID: <4FCC37CE.3080203@gmail.com> (raw)
In-Reply-To: <4FCC1D68.8060406@kernel.org>
> In changelog, Bartlomiej said.
>
> My particular test case (on a ARM EXYNOS4 device with 512 MiB, which means
> 131072 standard 4KiB pages in 'Normal' zone) is to:
>
> - allocate 120000 pages for kernel's usage
> - free every second page (60000 pages) of memory just allocated
> - allocate and use 60000 pages from user space
> - free remaining 60000 pages of kernel memory
> (now we have fragmented memory occupied mostly by user space pages)
> - try to allocate 100 order-9 (2048 KiB) pages for kernel's usage
>
> The results:
> - with compaction disabled I get 11 successful allocations
> - with compaction enabled - 14 successful allocations
> - with this patch I'm able to get all 100 successful allocations
>
> I think above workload is really really artificial and theoretical so I didn't like
> this patch but Mel seem to like it. :(
>
> Quote from Mel
> " Ok, that is indeed an adverse workload that the current system will not
> properly deal with. I think you are right to try fixing this but may need
> a different approach that takes the cost out of the allocation/free path
> and moves it the compaction path."
>
> We can correct this patch to work but at least need justification about it.
> Do we really need this patch for such artificial workload?
> what do you think?
I'm ok to resubmit. But please change the thread.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Hugh Dickins <hughd@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
Dave Jones <davej@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Cong Wang <amwang@redhat.com>,
Markus Trippelsdorf <markus@trippelsdorf.de>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kosaki.motohiro@gmail.com
Subject: Re: WARNING: at mm/page-writeback.c:1990 __set_page_dirty_nobuffers+0x13a/0x170()
Date: Mon, 04 Jun 2012 00:21:34 -0400 [thread overview]
Message-ID: <4FCC37CE.3080203@gmail.com> (raw)
In-Reply-To: <4FCC1D68.8060406@kernel.org>
> In changelog, Bartlomiej said.
>
> My particular test case (on a ARM EXYNOS4 device with 512 MiB, which means
> 131072 standard 4KiB pages in 'Normal' zone) is to:
>
> - allocate 120000 pages for kernel's usage
> - free every second page (60000 pages) of memory just allocated
> - allocate and use 60000 pages from user space
> - free remaining 60000 pages of kernel memory
> (now we have fragmented memory occupied mostly by user space pages)
> - try to allocate 100 order-9 (2048 KiB) pages for kernel's usage
>
> The results:
> - with compaction disabled I get 11 successful allocations
> - with compaction enabled - 14 successful allocations
> - with this patch I'm able to get all 100 successful allocations
>
> I think above workload is really really artificial and theoretical so I didn't like
> this patch but Mel seem to like it. :(
>
> Quote from Mel
> " Ok, that is indeed an adverse workload that the current system will not
> properly deal with. I think you are right to try fixing this but may need
> a different approach that takes the cost out of the allocation/free path
> and moves it the compaction path."
>
> We can correct this patch to work but at least need justification about it.
> Do we really need this patch for such artificial workload?
> what do you think?
I'm ok to resubmit. But please change the thread.
next prev parent reply other threads:[~2012-06-04 4:21 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-30 16:33 WARNING: at mm/page-writeback.c:1990 __set_page_dirty_nobuffers+0x13a/0x170() Dave Jones
2012-05-30 16:33 ` Dave Jones
2012-05-31 0:57 ` Dave Jones
2012-05-31 0:57 ` Dave Jones
2012-06-01 2:31 ` Dave Jones
2012-06-01 2:31 ` Dave Jones
2012-06-01 2:43 ` Linus Torvalds
2012-06-01 2:43 ` Linus Torvalds
2012-06-01 13:43 ` Dave Jones
2012-06-01 13:43 ` Dave Jones
2012-06-01 8:44 ` Hugh Dickins
2012-06-01 8:44 ` Hugh Dickins
2012-06-01 8:51 ` KOSAKI Motohiro
2012-06-01 8:51 ` KOSAKI Motohiro
2012-06-01 9:08 ` Hugh Dickins
2012-06-01 9:08 ` Hugh Dickins
2012-06-01 9:12 ` KOSAKI Motohiro
2012-06-01 9:12 ` KOSAKI Motohiro
2012-06-01 14:09 ` Dave Jones
2012-06-01 14:09 ` Dave Jones
2012-06-01 14:14 ` Dave Jones
2012-06-01 14:14 ` Dave Jones
2012-06-01 16:12 ` Dave Jones
2012-06-01 16:12 ` Dave Jones
2012-06-01 17:16 ` Dave Jones
2012-06-01 17:16 ` Dave Jones
2012-06-01 22:17 ` Hugh Dickins
2012-06-01 22:17 ` Hugh Dickins
2012-06-02 1:45 ` Linus Torvalds
2012-06-02 1:45 ` Linus Torvalds
2012-06-02 4:40 ` Hugh Dickins
2012-06-02 4:58 ` Linus Torvalds
2012-06-02 4:58 ` Linus Torvalds
2012-06-02 7:20 ` Hugh Dickins
2012-06-02 7:20 ` Hugh Dickins
2012-06-02 7:17 ` Markus Trippelsdorf
2012-06-02 7:17 ` Markus Trippelsdorf
2012-06-02 7:22 ` Hugh Dickins
2012-06-02 7:22 ` Hugh Dickins
2012-06-02 7:27 ` [PATCH] mm: fix warning in __set_page_dirty_nobuffers Hugh Dickins
2012-06-02 7:27 ` Hugh Dickins
2012-06-03 18:15 ` WARNING: at mm/page-writeback.c:1990 __set_page_dirty_nobuffers+0x13a/0x170() Dave Jones
2012-06-03 18:15 ` Dave Jones
2012-06-03 18:23 ` Linus Torvalds
2012-06-03 18:23 ` Linus Torvalds
2012-06-03 18:31 ` Dave Jones
2012-06-03 18:31 ` Dave Jones
2012-06-03 20:53 ` Dave Jones
2012-06-03 20:53 ` Dave Jones
2012-06-03 21:59 ` Linus Torvalds
2012-06-03 21:59 ` Linus Torvalds
2012-06-03 22:13 ` Dave Jones
2012-06-03 22:13 ` Dave Jones
2012-06-03 22:29 ` Hugh Dickins
2012-06-03 22:29 ` Hugh Dickins
2012-06-03 22:17 ` Hugh Dickins
2012-06-03 22:17 ` Hugh Dickins
2012-06-03 23:13 ` Linus Torvalds
2012-06-03 23:13 ` Linus Torvalds
2012-06-04 0:46 ` KOSAKI Motohiro
2012-06-04 0:46 ` KOSAKI Motohiro
2012-06-04 1:18 ` Hugh Dickins
2012-06-04 1:18 ` Hugh Dickins
2012-06-04 1:21 ` Minchan Kim
2012-06-04 1:21 ` Minchan Kim
2012-06-04 1:26 ` KOSAKI Motohiro
2012-06-04 1:26 ` KOSAKI Motohiro
2012-06-04 2:30 ` Minchan Kim
2012-06-04 2:30 ` Minchan Kim
2012-06-04 1:10 ` Minchan Kim
2012-06-04 1:10 ` Minchan Kim
2012-06-04 1:41 ` Hugh Dickins
2012-06-04 1:41 ` Hugh Dickins
2012-06-04 1:47 ` KOSAKI Motohiro
2012-06-04 1:47 ` KOSAKI Motohiro
2012-06-04 2:28 ` Minchan Kim
2012-06-04 2:28 ` Minchan Kim
2012-06-04 4:21 ` KOSAKI Motohiro [this message]
2012-06-04 4:21 ` KOSAKI Motohiro
2012-06-04 13:37 ` Bartlomiej Zolnierkiewicz
2012-06-04 13:37 ` Bartlomiej Zolnierkiewicz
2012-06-01 16:16 ` Markus Trippelsdorf
2012-06-01 16:16 ` Markus Trippelsdorf
2012-06-01 16:28 ` Linus Torvalds
2012-06-01 16:28 ` Linus Torvalds
2012-06-01 16:39 ` Markus Trippelsdorf
2012-06-01 16:39 ` Markus Trippelsdorf
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=4FCC37CE.3080203@gmail.com \
--to=kosaki.motohiro@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=amwang@redhat.com \
--cc=b.zolnierkie@samsung.com \
--cc=davej@redhat.com \
--cc=hughd@google.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=markus@trippelsdorf.de \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=torvalds@linux-foundation.org \
/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.