From: Dave Hansen <dave.hansen@intel.com>
To: Xishi Qiu <qiuxishi@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
iamjoonsoo.kim@lge.com, alexander.h.duyck@redhat.com,
sasha.levin@oracle.com
Cc: Linux MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: add the block to the tail of the list in expand()
Date: Fri, 31 Jul 2015 16:24:02 -0700 [thread overview]
Message-ID: <55BC0392.2070205@intel.com> (raw)
In-Reply-To: <55BB4027.7080200@huawei.com>
On 07/31/2015 02:30 AM, Xishi Qiu wrote:
> __free_one_page() will judge whether the the next-highest order is free,
> then add the block to the tail or not. So when we split large order block,
> add the small block to the tail, it will reduce fragment.
It's an interesting idea, but what does it do in practice? Can you
measure a decrease in fragmentation?
Further, the comment above the function says:
* The order of subdivision here is critical for the IO subsystem.
* Please do not alter this order without good reasons and regression
* testing.
Has there been regression testing?
Also, this might not do very much good in practice. If you are
splitting a high-order page, you are doing the split because the
lower-order lists are empty. So won't that list_add() be to an empty
list most of the time? Or does the __rmqueue_fallback()
largest->smallest logic dominate?
--
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: Dave Hansen <dave.hansen@intel.com>
To: Xishi Qiu <qiuxishi@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
iamjoonsoo.kim@lge.com, alexander.h.duyck@redhat.com,
sasha.levin@oracle.com
Cc: Linux MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: add the block to the tail of the list in expand()
Date: Fri, 31 Jul 2015 16:24:02 -0700 [thread overview]
Message-ID: <55BC0392.2070205@intel.com> (raw)
In-Reply-To: <55BB4027.7080200@huawei.com>
On 07/31/2015 02:30 AM, Xishi Qiu wrote:
> __free_one_page() will judge whether the the next-highest order is free,
> then add the block to the tail or not. So when we split large order block,
> add the small block to the tail, it will reduce fragment.
It's an interesting idea, but what does it do in practice? Can you
measure a decrease in fragmentation?
Further, the comment above the function says:
* The order of subdivision here is critical for the IO subsystem.
* Please do not alter this order without good reasons and regression
* testing.
Has there been regression testing?
Also, this might not do very much good in practice. If you are
splitting a high-order page, you are doing the split because the
lower-order lists are empty. So won't that list_add() be to an empty
list most of the time? Or does the __rmqueue_fallback()
largest->smallest logic dominate?
next prev parent reply other threads:[~2015-07-31 23:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 9:30 [PATCH] mm: add the block to the tail of the list in expand() Xishi Qiu
2015-07-31 9:30 ` Xishi Qiu
2015-07-31 23:24 ` Dave Hansen [this message]
2015-07-31 23:24 ` Dave Hansen
2015-08-03 2:05 ` Xishi Qiu
2015-08-03 2:05 ` Xishi Qiu
2015-08-03 4:10 ` Dave Hansen
2015-08-03 4:10 ` Dave Hansen
2015-08-04 1:13 ` Xishi Qiu
2015-08-04 1:13 ` Xishi Qiu
2015-08-04 14:27 ` Dave Hansen
2015-08-04 14:27 ` Dave Hansen
2015-08-05 7:54 ` Xishi Qiu
2015-08-05 7:54 ` Xishi Qiu
2015-08-05 14:47 ` Dave Hansen
2015-08-05 14:47 ` Dave Hansen
2015-08-14 7:55 ` Xishi Qiu
2015-08-14 7:55 ` Xishi Qiu
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=55BC0392.2070205@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=qiuxishi@huawei.com \
--cc=sasha.levin@oracle.com \
--cc=vbabka@suse.cz \
/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.