On Tue, Apr 09, 2013 at 09:56:58PM -0400, KOSAKI Motohiro wrote:
> On Tue, Apr 9, 2013 at 6:43 PM, Naoya Horiguchi
...
> > MIGRATE_ISOLTE is changed only within the range [start_pfn, end_pfn)
> > given as the argument of __offline_pages (see also
> > start_isolate_page_range),
> > so it's set
On Tue, Apr 9, 2013 at 6:43 PM, Naoya Horiguchi
wrote:
> On Tue, Apr 09, 2013 at 05:27:44PM -0400, KOSAKI Motohiro wrote:
>> >> numa_node_id() is really silly. This might lead to allocate from
>> >> offlining node.
>> >
>> > Right, it should've been alloc_huge_page().
>> >
>> >> and,
On Tue, Apr 09, 2013 at 05:27:44PM -0400, KOSAKI Motohiro wrote:
> >> numa_node_id() is really silly. This might lead to allocate from offlining
> >> node.
> >
> > Right, it should've been alloc_huge_page().
> >
> >> and, offline_pages() should mark hstate as isolated likes normal pages for
> >>
>> numa_node_id() is really silly. This might lead to allocate from offlining
>> node.
>
> Right, it should've been alloc_huge_page().
>
>> and, offline_pages() should mark hstate as isolated likes normal pages for
>> prohibiting
>> new allocation at first.
>
> It seems that
On Fri, Apr 05, 2013 at 08:13:47PM -0400, KOSAKI Motohiro wrote:
> (3/22/13 4:23 PM), Naoya Horiguchi wrote:
> > Currently we can't offline memory blocks which contain hugepages because
> > a hugepage is considered as an unmovable page. But now with this patch
> > series, a hugepage has become
On Fri, Apr 05, 2013 at 08:13:47PM -0400, KOSAKI Motohiro wrote:
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
Currently we can't offline memory blocks which contain hugepages because
a hugepage is considered as an unmovable page. But now with this patch
series, a hugepage has become movable,
numa_node_id() is really silly. This might lead to allocate from offlining
node.
Right, it should've been alloc_huge_page().
and, offline_pages() should mark hstate as isolated likes normal pages for
prohibiting
new allocation at first.
It seems that alloc_migrate_target() calls
On Tue, Apr 09, 2013 at 05:27:44PM -0400, KOSAKI Motohiro wrote:
numa_node_id() is really silly. This might lead to allocate from offlining
node.
Right, it should've been alloc_huge_page().
and, offline_pages() should mark hstate as isolated likes normal pages for
prohibiting
new
On Tue, Apr 9, 2013 at 6:43 PM, Naoya Horiguchi
n-horigu...@ah.jp.nec.com wrote:
On Tue, Apr 09, 2013 at 05:27:44PM -0400, KOSAKI Motohiro wrote:
numa_node_id() is really silly. This might lead to allocate from
offlining node.
Right, it should've been alloc_huge_page().
and,
On Tue, Apr 09, 2013 at 09:56:58PM -0400, KOSAKI Motohiro wrote:
On Tue, Apr 9, 2013 at 6:43 PM, Naoya Horiguchi
...
MIGRATE_ISOLTE is changed only within the range [start_pfn, end_pfn)
given as the argument of __offline_pages (see also
start_isolate_page_range),
so it's set only for
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
> Currently we can't offline memory blocks which contain hugepages because
> a hugepage is considered as an unmovable page. But now with this patch
> series, a hugepage has become movable, so by using hugepage migration we
> can offline such memory blocks.
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
Currently we can't offline memory blocks which contain hugepages because
a hugepage is considered as an unmovable page. But now with this patch
series, a hugepage has become movable, so by using hugepage migration we
can offline such memory blocks.
On Wed 27-03-13 17:29:19, Naoya Horiguchi wrote:
> On Wed, Mar 27, 2013 at 03:19:21PM +0100, Michal Hocko wrote:
[...]
> > If we made sure that all page on the hugepage_freelists have reference
> > 0 (which is now not the case and it is yet another source of confusion)
> > then the whole loop
On Wed, Mar 27, 2013 at 05:29:19PM -0400, Naoya Horiguchi wrote:
...
> > If we made sure that all page on the hugepage_freelists have reference
> > 0 (which is now not the case and it is yet another source of confusion)
> > then the whole loop could be replaced by page_count check.
>
> I think
On Wed, Mar 27, 2013 at 03:19:21PM +0100, Michal Hocko wrote:
> On Tue 26-03-13 14:23:24, Naoya Horiguchi wrote:
> > On Mon, Mar 25, 2013 at 04:09:52PM +0100, Michal Hocko wrote:
> > > On Fri 22-03-13 16:23:54, Naoya Horiguchi wrote:
> > ...
> > > > index d9d3dd7..ef79871 100644
> > > > ---
On Tue, Mar 26, 2013 at 05:31:51PM +0530, Aneesh Kumar K.V wrote:
> Naoya Horiguchi writes:
>
> > +/* Returns true for head pages of in-use hugepages, otherwise returns
> > false. */
> > +bool is_hugepage_movable(struct page *hpage)
> > +{
> > + struct page *page;
> > + struct hstate *h;
>
On Tue 26-03-13 14:23:24, Naoya Horiguchi wrote:
> On Mon, Mar 25, 2013 at 04:09:52PM +0100, Michal Hocko wrote:
> > On Fri 22-03-13 16:23:54, Naoya Horiguchi wrote:
> ...
> > > index d9d3dd7..ef79871 100644
> > > --- v3.9-rc3.orig/mm/hugetlb.c
> > > +++ v3.9-rc3/mm/hugetlb.c
> > > @@ -844,6
On Tue 26-03-13 14:23:24, Naoya Horiguchi wrote:
On Mon, Mar 25, 2013 at 04:09:52PM +0100, Michal Hocko wrote:
On Fri 22-03-13 16:23:54, Naoya Horiguchi wrote:
...
index d9d3dd7..ef79871 100644
--- v3.9-rc3.orig/mm/hugetlb.c
+++ v3.9-rc3/mm/hugetlb.c
@@ -844,6 +844,36 @@ static int
On Tue, Mar 26, 2013 at 05:31:51PM +0530, Aneesh Kumar K.V wrote:
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
+/* Returns true for head pages of in-use hugepages, otherwise returns
false. */
+bool is_hugepage_movable(struct page *hpage)
+{
+ struct page *page;
+ struct
On Wed, Mar 27, 2013 at 03:19:21PM +0100, Michal Hocko wrote:
On Tue 26-03-13 14:23:24, Naoya Horiguchi wrote:
On Mon, Mar 25, 2013 at 04:09:52PM +0100, Michal Hocko wrote:
On Fri 22-03-13 16:23:54, Naoya Horiguchi wrote:
...
index d9d3dd7..ef79871 100644
---
On Wed, Mar 27, 2013 at 05:29:19PM -0400, Naoya Horiguchi wrote:
...
If we made sure that all page on the hugepage_freelists have reference
0 (which is now not the case and it is yet another source of confusion)
then the whole loop could be replaced by page_count check.
I think that free
On Wed 27-03-13 17:29:19, Naoya Horiguchi wrote:
On Wed, Mar 27, 2013 at 03:19:21PM +0100, Michal Hocko wrote:
[...]
If we made sure that all page on the hugepage_freelists have reference
0 (which is now not the case and it is yet another source of confusion)
then the whole loop could be
On Mon, Mar 25, 2013 at 04:09:52PM +0100, Michal Hocko wrote:
> On Fri 22-03-13 16:23:54, Naoya Horiguchi wrote:
...
> > index d9d3dd7..ef79871 100644
> > --- v3.9-rc3.orig/mm/hugetlb.c
> > +++ v3.9-rc3/mm/hugetlb.c
> > @@ -844,6 +844,36 @@ static int free_pool_huge_page(struct hstate *h,
> >
Naoya Horiguchi writes:
> +/* Returns true for head pages of in-use hugepages, otherwise returns false.
> */
> +bool is_hugepage_movable(struct page *hpage)
> +{
> + struct page *page;
> + struct hstate *h;
> + bool ret = false;
> +
> + VM_BUG_ON(!PageHuge(hpage));
> + /*
>
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
+/* Returns true for head pages of in-use hugepages, otherwise returns false.
*/
+bool is_hugepage_movable(struct page *hpage)
+{
+ struct page *page;
+ struct hstate *h;
+ bool ret = false;
+
+
On Mon, Mar 25, 2013 at 04:09:52PM +0100, Michal Hocko wrote:
On Fri 22-03-13 16:23:54, Naoya Horiguchi wrote:
...
index d9d3dd7..ef79871 100644
--- v3.9-rc3.orig/mm/hugetlb.c
+++ v3.9-rc3/mm/hugetlb.c
@@ -844,6 +844,36 @@ static int free_pool_huge_page(struct hstate *h,
nodemask_t
On Fri 22-03-13 16:23:54, Naoya Horiguchi wrote:
> Currently we can't offline memory blocks which contain hugepages because
> a hugepage is considered as an unmovable page. But now with this patch
> series, a hugepage has become movable, so by using hugepage migration we
> can offline such memory
On Fri 22-03-13 16:23:54, Naoya Horiguchi wrote:
Currently we can't offline memory blocks which contain hugepages because
a hugepage is considered as an unmovable page. But now with this patch
series, a hugepage has become movable, so by using hugepage migration we
can offline such memory
Currently we can't offline memory blocks which contain hugepages because
a hugepage is considered as an unmovable page. But now with this patch
series, a hugepage has become movable, so by using hugepage migration we
can offline such memory blocks.
What's different from other users of hugepage
Currently we can't offline memory blocks which contain hugepages because
a hugepage is considered as an unmovable page. But now with this patch
series, a hugepage has become movable, so by using hugepage migration we
can offline such memory blocks.
What's different from other users of hugepage
30 matches
Mail list logo
