of get_user_pages() but it makes sure that all pages come from
non-movable zone via additional page migration.
Cc: Andrew Morton
Cc: Mel Gorman
Cc: KAMEZAWA Hiroyuki
Cc: Yasuaki Ishimatsu
Cc: Jeff Moyer
Cc: Minchan Kim
Cc: Zach Brown
Reviewed-by: Tang Chen
Reviewed-by: Gu Zheng
Signed-off-by: Lin Feng
Hi Minchan,
On 02/05/2013 03:45 PM, Minchan Kim wrote:
>> So it may not a good idea that we all fall into calling the *non_movable*
>> version of
>> > GUP when CONFIG_MIGRATE_ISOLATE is on. What do you think?
> Frankly speaking, I can't understand Mel's comment.
> AFAIUC, he said GUP checks the
Hi Minchan,
On 02/05/2013 03:45 PM, Minchan Kim wrote:
So it may not a good idea that we all fall into calling the *non_movable*
version of
GUP when CONFIG_MIGRATE_ISOLATE is on. What do you think?
Frankly speaking, I can't understand Mel's comment.
AFAIUC, he said GUP checks the page
the negative return value bug pointed out by Andrew and other
suggestions pointed out by Andrew and Jeff.
Patch2:
- Kill the CONFIG_MEMORY_HOTREMOVE dependence suggested by Jeff.
---
Lin Feng (2):
mm: hotplug: implement non-movable version of get_user_pages() called
get_user_pages_non_movable
...@redhat.com
Cc: Minchan Kim minc...@kernel.org
Cc: Zach Brown z...@redhat.com
Reviewed-by: Tang Chen tangc...@cn.fujitsu.com
Reviewed-by: Gu Zheng guz.f...@cn.fujitsu.com
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
---
include/linux/mm.h |3 ++
include/linux/mmzone.h |4 ++
mm
Viro v...@zeniv.linux.org.uk
Cc: Andrew Morton a...@linux-foundation.org
Cc: Jeff Moyer jmo...@redhat.com
Cc: Minchan Kim minc...@kernel.org
Cc: Zach Brown z...@redhat.com
Reviewed-by: Tang Chen tangc...@cn.fujitsu.com
Reviewed-by: Gu Zheng guz.f...@cn.fujitsu.com
Signed-off-by: Lin Feng linf
On 02/05/2013 01:25 PM, Minchan Kim wrote:
> Hi Lin,
>
> On Tue, Feb 05, 2013 at 12:42:48PM +0800, Lin Feng wrote:
>> Hi Minchan,
>>
>> On 02/05/2013 08:58 AM, Minchan Kim wrote:
>>> Hello,
>>>
>>> On Mon, Feb 04, 2013 at 06:04:06PM +0800,
Hi Zach,
On 02/05/2013 07:02 AM, Zach Brown wrote:
>>> index 71f613c..0e9b30a 100644
>>> --- a/fs/aio.c
>>> +++ b/fs/aio.c
>>> @@ -138,9 +138,15 @@ static int aio_setup_ring(struct kioctx *ctx)
>>> }
>>>
>>> dprintk("mmap address: 0x%08lx\n", info->mmap_base);
>>> +#ifdef
Hi Jeff,
On 02/04/2013 11:18 PM, Jeff Moyer wrote:
>> ---
>> fs/aio.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/fs/aio.c b/fs/aio.c
>> index 71f613c..0e9b30a 100644
>> --- a/fs/aio.c
>> +++ b/fs/aio.c
>> @@ -138,9 +138,15 @@ static int aio_setup_ring(struct kioctx *ctx)
Hi Minchan,
On 02/05/2013 08:58 AM, Minchan Kim wrote:
> Hello,
>
> On Mon, Feb 04, 2013 at 06:04:06PM +0800, Lin Feng wrote:
>> Currently get_user_pages() always tries to allocate pages from movable zone,
>> as discussed in thread https://lkml.org/lkml/2012/11/29/69, i
Hi Andrew,
On 02/05/2013 08:06 AM, Andrew Morton wrote:
>
> melreadthis
>
> On Mon, 4 Feb 2013 18:04:07 +0800
> Lin Feng wrote:
>
>> get_user_pages() always tries to allocate pages from movable zone, which is
>> not
>> reliable to memory hotremove fram
of get_user_pages() but it makes sure that all pages come from
non-movable zone via additional page migration.
Cc: Andrew Morton
Cc: Mel Gorman
Cc: KAMEZAWA Hiroyuki
Cc: Yasuaki Ishimatsu
Reviewed-by: Tang Chen
Reviewed-by: Gu Zheng
Signed-off-by: Lin Feng
---
include/linux/mm.h | 5
include
migration.
The 2nd patch gets around the aio ring pages can't be migrated bug caused by
get_user_pages() via using the new function. It only works when configed with
CONFIG_MEMORY_HOTREMOVE, otherwise it uses the old version of get_user_pages().
Lin Feng (2):
mm: hotplug: implement non-movable version
Reviewed-by: Tang Chen
Reviewed-by: Gu Zheng
Signed-off-by: Lin Feng
---
fs/aio.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/aio.c b/fs/aio.c
index 71f613c..0e9b30a 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -138,9 +138,15 @@ static int aio_setup_ring(struct kioctx *ctx
migration.
The 2nd patch gets around the aio ring pages can't be migrated bug caused by
get_user_pages() via using the new function. It only works when configed with
CONFIG_MEMORY_HOTREMOVE, otherwise it uses the old version of get_user_pages().
Lin Feng (2):
mm: hotplug: implement non-movable version
...@zeniv.linux.org.uk
Cc: Andrew Morton a...@linux-foundation.org
Reviewed-by: Tang Chen tangc...@cn.fujitsu.com
Reviewed-by: Gu Zheng guz.f...@cn.fujitsu.com
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
---
fs/aio.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/aio.c b/fs/aio.c
index
tangc...@cn.fujitsu.com
Reviewed-by: Gu Zheng guz.f...@cn.fujitsu.com
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
---
include/linux/mm.h | 5
include/linux/mmzone.h | 4
mm/memory.c| 63 ++
mm/page_isolation.c| 5
Hi Andrew,
On 02/05/2013 08:06 AM, Andrew Morton wrote:
melreadthis
On Mon, 4 Feb 2013 18:04:07 +0800
Lin Feng linf...@cn.fujitsu.com wrote:
get_user_pages() always tries to allocate pages from movable zone, which is
not
reliable to memory hotremove framework in some case
Hi Minchan,
On 02/05/2013 08:58 AM, Minchan Kim wrote:
Hello,
On Mon, Feb 04, 2013 at 06:04:06PM +0800, Lin Feng wrote:
Currently get_user_pages() always tries to allocate pages from movable zone,
as discussed in thread https://lkml.org/lkml/2012/11/29/69, in some case
users
Hi Jeff,
On 02/04/2013 11:18 PM, Jeff Moyer wrote:
---
fs/aio.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/aio.c b/fs/aio.c
index 71f613c..0e9b30a 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -138,9 +138,15 @@ static int aio_setup_ring(struct kioctx *ctx)
}
Hi Zach,
On 02/05/2013 07:02 AM, Zach Brown wrote:
index 71f613c..0e9b30a 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -138,9 +138,15 @@ static int aio_setup_ring(struct kioctx *ctx)
}
dprintk(mmap address: 0x%08lx\n, info-mmap_base);
+#ifdef CONFIG_MEMORY_HOTREMOVE
+
On 02/05/2013 01:25 PM, Minchan Kim wrote:
Hi Lin,
On Tue, Feb 05, 2013 at 12:42:48PM +0800, Lin Feng wrote:
Hi Minchan,
On 02/05/2013 08:58 AM, Minchan Kim wrote:
Hello,
On Mon, Feb 04, 2013 at 06:04:06PM +0800, Lin Feng wrote:
Currently get_user_pages() always tries to allocate
Hi Michal,
On 01/18/2013 09:58 PM, Michal Hocko wrote:
> On Fri 18-01-13 15:54:36, Lin Feng wrote:
>> Besides page_isolation.c selected by MEMORY_ISOLATION under MEMORY_HOTPLUG
>> is also such case, move it too.
>
> Yes, it seems that only HOTREMOVE needs MEMORY_ISOL
Hi Michal,
On 01/18/2013 09:58 PM, Michal Hocko wrote:
On Fri 18-01-13 15:54:36, Lin Feng wrote:
Besides page_isolation.c selected by MEMORY_ISOLATION under MEMORY_HOTPLUG
is also such case, move it too.
Yes, it seems that only HOTREMOVE needs MEMORY_ISOLATION but that should
be done
Hi Michal,
On 01/17/2013 09:05 PM, Michal Hocko wrote:
> On Thu 17-01-13 18:37:10, Lin Feng wrote:
> [...]
>>> > > I am still not sure I understand the relation to MEMORY_HOTREMOVE.
>>> > > Is register_page_bootmem_info_node required/helpful even if
>>>
page_isolation.c selected by MEMORY_ISOLATION under MEMORY_HOTPLUG
is also such case, move it too.
Signed-off-by: Lin Feng
---
mm/Kconfig |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index f8c5799..a96c010 100644
--- a/mm/Kconfig
+++ b/mm
Hi Michal,
On 01/16/2013 10:14 PM, Michal Hocko wrote:
> On Wed 16-01-13 16:14:18, Lin Feng wrote:
> [...]
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 278e3ab..f8c5799 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -162,10 +162,18 @@ config MOVABLE_N
Hi Michal,
On 01/16/2013 10:14 PM, Michal Hocko wrote:
On Wed 16-01-13 16:14:18, Lin Feng wrote:
[...]
diff --git a/mm/Kconfig b/mm/Kconfig
index 278e3ab..f8c5799 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -162,10 +162,18 @@ config MOVABLE_NODE
Say Y here if you want to hotplug
page_isolation.c selected by MEMORY_ISOLATION under MEMORY_HOTPLUG
is also such case, move it too.
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
---
mm/Kconfig |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index f8c5799..a96c010 100644
--- a/mm
Hi Michal,
On 01/17/2013 09:05 PM, Michal Hocko wrote:
On Thu 17-01-13 18:37:10, Lin Feng wrote:
[...]
I am still not sure I understand the relation to MEMORY_HOTREMOVE.
Is register_page_bootmem_info_node required/helpful even if
!CONFIG_MEMORY_HOTREMOVE?
From old kenrel's view
It's implemented by adding a new Kconfig option named
CONFIG_HAVE_BOOTMEM_INFO_NODE, which will be automatically selected by
memory-hotplug feature fully supported archs(currently only on x86_64).
Reported-by: Michal Hocko
Signed-off-by: Lin Feng
---
ChangeLog v2->v3:
- Rename the patch ti
New added, remove unimplemented functions suggested by Michal.
ChangeLog v1->v2:
1) patch 1/2:
- Add a Kconfig option named HAVE_BOOTMEM_INFO_NODE suggested by Michal, which
will be automatically selected by supported archs(currently only on x86_64).
Lin Feng (1):
memory-hotplug:
from top to
end.
Signed-off-by: Michal Hocko
Signed-off-by: Lin Feng
---
arch/ia64/mm/discontig.c |5 -
arch/powerpc/mm/init_64.c |5 -
arch/s390/mm/vmem.c |6 --
arch/sparc/mm/init_64.c |5 -
4 files changed, 0 insertions(+), 21 deletions(-)
diff --git
added, remove unimplemented functions suggested by Michal.
ChangeLog v1-v2:
1) patch 1/2:
- Add a Kconfig option named HAVE_BOOTMEM_INFO_NODE suggested by Michal, which
will be automatically selected by supported archs(currently only on x86_64).
Lin Feng (1):
memory-hotplug: revert
() and flesh out from top to
end.
Signed-off-by: Michal Hocko mho...@suse.cz
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
---
arch/ia64/mm/discontig.c |5 -
arch/powerpc/mm/init_64.c |5 -
arch/s390/mm/vmem.c |6 --
arch/sparc/mm/init_64.c |5 -
4 files
It's implemented by adding a new Kconfig option named
CONFIG_HAVE_BOOTMEM_INFO_NODE, which will be automatically selected by
memory-hotplug feature fully supported archs(currently only on x86_64).
Reported-by: Michal Hocko mho...@suse.cz
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
Hi Michal,
On 01/15/2013 10:20 PM, Michal Hocko wrote:
>> +#else
>> > +void register_page_bootmem_info_node(struct pglist_data *pgdat)
>> > +{
>> > + /* TODO */
>> > +}
> I think that TODO is misleading here because the function should be
> empty if !CONFIG_HAVE_BOOTMEM_INFO_NODE. I would also
Hi Michal,
I have updated to V2 version according to what you said, would you please take
a look
if it conforms to what you think?
thanks,
linfeng
On 01/15/2013 02:43 AM, Michal Hocko wrote:
> This is just ugly. Could you please add something like HAVE_BOOTMEM_INFO_NODE
> or something with a
CONFIG_HAVE_BOOTMEM_INFO_NODE, which will be automatically selected by
supported archs(currently only on x86_64).
Reported-by: Michal Hocko
Signed-off-by: Lin Feng
---
ChangeLog v1->v2:
- Add a Kconfig option named HAVE_BOOTMEM_INFO_NODE suggested by Michal, which
will be automatically selected by suppor
Hi Michal,
On 01/15/2013 10:20 PM, Michal Hocko wrote:
+#else
+void register_page_bootmem_info_node(struct pglist_data *pgdat)
+{
+ /* TODO */
+}
I think that TODO is misleading here because the function should be
empty if !CONFIG_HAVE_BOOTMEM_INFO_NODE. I would also suggest updating
CONFIG_HAVE_BOOTMEM_INFO_NODE, which will be automatically selected by
supported archs(currently only on x86_64).
Reported-by: Michal Hocko mho...@suse.cz
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
---
ChangeLog v1-v2:
- Add a Kconfig option named HAVE_BOOTMEM_INFO_NODE suggested by Michal, which
Hi Michal,
I have updated to V2 version according to what you said, would you please take
a look
if it conforms to what you think?
thanks,
linfeng
On 01/15/2013 02:43 AM, Michal Hocko wrote:
This is just ugly. Could you please add something like HAVE_BOOTMEM_INFO_NODE
or something with a
is a hotplug generic
function but falling back to call platform related function
register_page_bootmem_memmap().
Other platforms such as powerpc it's not implemented, so on such platforms,
revert them as empty as they were before.
Reported-by: Michal Hocko
Signed-off-by: Lin Feng
---
mm
is a hotplug generic
function but falling back to call platform related function
register_page_bootmem_memmap().
Other platforms such as powerpc it's not implemented, so on such platforms,
revert them as empty as they were before.
Reported-by: Michal Hocko mho...@suse.cz
Signed-off-by: Lin Feng
e
except for this,
Tested-by: Lin Feng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
It looks fine to me.
Tested-by: Lin Feng
On 01/11/2013 05:53 PM, Michal Hocko wrote:
> Defconfig for x86_64 complains:
> arch/x86/mm/init_64.c: In function ‘vmemmap_free’:
> arch/x86/mm/init_64.c:1317: error: implicit declaration of function
> ‘remove_pagetable’
>
> vmemmap
Hi Michal,
On 01/11/2013 06:47 PM, Michal Hocko wrote:
> Signed-off-by: Michal Hocko
> ---
> arch/x86/mm/init_64.c |3 +++
> include/linux/mm.h|2 ++
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index ddd3b58..d8edf52 100644
>
Hi Michal,
On 01/11/2013 06:47 PM, Michal Hocko wrote:
Signed-off-by: Michal Hocko mho...@suse.cz
---
arch/x86/mm/init_64.c |3 +++
include/linux/mm.h|2 ++
2 files changed, 5 insertions(+)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index ddd3b58..d8edf52
It looks fine to me.
Tested-by: Lin Feng linf...@cn.fujitsu.com
On 01/11/2013 05:53 PM, Michal Hocko wrote:
Defconfig for x86_64 complains:
arch/x86/mm/init_64.c: In function ‘vmemmap_free’:
arch/x86/mm/init_64.c:1317: error: implicit declaration of function
‘remove_pagetable
+#include linux/memory_hotplug.h
except for this,
Tested-by: Lin Feng linf...@cn.fujitsu.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On 01/08/2013 05:23 AM, Andrew Morton wrote:
> On Mon, 7 Jan 2013 11:41:36 +0800
> Lin Feng wrote:
>
>> The memmove span covers from (next+1) to the end of the array, and the index
>> of next is (i+1), so the index of (next+1) is (i+2). So the size of remaining
>> a
On 01/08/2013 05:23 AM, Andrew Morton wrote:
On Mon, 7 Jan 2013 11:41:36 +0800
Lin Feng linf...@cn.fujitsu.com wrote:
The memmove span covers from (next+1) to the end of the array, and the index
of next is (i+1), so the index of (next+1) is (i+2). So the size of remaining
array elements
The memmove span covers from (next+1) to the end of the array, and the index
of next is (i+1), so the index of (next+1) is (i+2). So the size of remaining
array elements is (type->cnt - (i + 2)).
Cc: Tejun Heo
Reviewed-by: Wanpeng Li
Signed-off-by: Lin Feng
---
ChangeLog v1->v2:
On 01/04/2013 11:01 PM, Tejun Heo wrote:
> On Fri, Jan 04, 2013 at 05:24:53PM +0800, Lin Feng wrote:
>> The memblock array is in ascending order and we traverse the memblock array
>> in
>> reverse order so we can add some simple check to reduce the search work.
>>
&
On 01/05/2013 09:04 AM, Wanpeng Li wrote:
> On Fri, Jan 04, 2013 at 05:10:50PM +0800, Lin Feng wrote:
>> The memmove span covers from (next+1) to the end of the array, and the index
>> of next is (i+1), so the index of (next+1) is (i+2). So the size of remaining
>> array e
On 01/04/2013 10:56 PM, Tejun Heo wrote:
> On Fri, Jan 04, 2013 at 05:10:50PM +0800, Lin Feng wrote:
>> The memmove span covers from (next+1) to the end of the array, and the index
>> of next is (i+1), so the index of (next+1) is (i+2). So the size of remaining
>> array e
On 01/04/2013 10:56 PM, Tejun Heo wrote:
On Fri, Jan 04, 2013 at 05:10:50PM +0800, Lin Feng wrote:
The memmove span covers from (next+1) to the end of the array, and the index
of next is (i+1), so the index of (next+1) is (i+2). So the size of remaining
array elements is (type-cnt - (i + 2
On 01/05/2013 09:04 AM, Wanpeng Li wrote:
On Fri, Jan 04, 2013 at 05:10:50PM +0800, Lin Feng wrote:
The memmove span covers from (next+1) to the end of the array, and the index
of next is (i+1), so the index of (next+1) is (i+2). So the size of remaining
array elements is (type-cnt - (i + 2
On 01/04/2013 11:01 PM, Tejun Heo wrote:
On Fri, Jan 04, 2013 at 05:24:53PM +0800, Lin Feng wrote:
The memblock array is in ascending order and we traverse the memblock array
in
reverse order so we can add some simple check to reduce the search work.
Tejun fix a underflow bug
The memmove span covers from (next+1) to the end of the array, and the index
of next is (i+1), so the index of (next+1) is (i+2). So the size of remaining
array elements is (type-cnt - (i + 2)).
Cc: Tejun Heo t...@kernel.org
Reviewed-by: Wanpeng Li liw...@linux.vnet.ibm.com
Signed-off-by: Lin
The memblock array is in ascending order and we traverse the memblock array in
reverse order so we can add some simple check to reduce the search work.
Tejun fix a underflow bug in 5d53cb27d8, but I think we could break there for
the same reason.
Cc: Tejun Heo
Signed-off-by: Lin Feng
---
mm
ove the remaining array elements until we find a none-mergable
element, but now we memmove everytime we find a neighboring compatible region.
I'm not sure if the trial is worth though.
Cc: Tejun Heo
Signed-off-by: Lin Feng
---
mm/memblock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
the remaining array elements until we find a none-mergable
element, but now we memmove everytime we find a neighboring compatible region.
I'm not sure if the trial is worth though.
Cc: Tejun Heo t...@kernel.org
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
---
mm/memblock.c | 2 +-
1 file changed, 1
The memblock array is in ascending order and we traverse the memblock array in
reverse order so we can add some simple check to reduce the search work.
Tejun fix a underflow bug in 5d53cb27d8, but I think we could break there for
the same reason.
Cc: Tejun Heo t...@kernel.org
Signed-off-by: Lin
On 12/28/2012 03:45 PM, Yinghai Lu wrote:
> On Thu, Dec 27, 2012 at 11:31 PM, Lin Feng wrote:
>> pci_reassigndev_resource_alignment() potentially calls
>> pci_specified_resource_alignment() twice, which is redundant.
>>
>> pci_is_r
On 12/28/2012 03:45 PM, Yinghai Lu wrote:
On Thu, Dec 27, 2012 at 11:31 PM, Lin Feng linf...@cn.fujitsu.com wrote:
pci_reassigndev_resource_alignment() potentially calls
pci_specified_resource_alignment() twice, which is redundant.
pci_is_reassigndev() is only called
, so also make some cleanup.
Signed-off-by: Lin Feng
Cc: Yinghai Lu
---
drivers/pci/pci.c | 16 ++--
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 5cb5820..789f401 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
, so also make some cleanup.
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
Cc: Yinghai Lu ying...@kernel.org
---
drivers/pci/pci.c | 16 ++--
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 5cb5820..789f401 100644
uld_stop+0x70/0x70
[] ? gs_change+0x13/0x13
Reported-by: Taku Izumi
Signed-off-by: Lin Feng
Signed-off-by: Gu Zheng
---
drivers/pci/pci-sysfs.c | 42 ++
1 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers
] kthread+0x9e/0xb0
[81525bc4] kernel_thread_helper+0x4/0x10
[81076fc0] ? kthread_freezable_should_stop+0x70/0x70
[81525bc0] ? gs_change+0x13/0x13
Reported-by: Taku Izumi izumi.t...@jp.fujitsu.com
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
Signed-off-by: Gu Zheng
the ranges in movable_map.map[] belongs, and calculates the
>>>>> low boundary of ZONE_MOVABLE for each node.
>>>>>
>>>>> Signed-off-by: Tang Chen
>>>>> Signed-off-by: Jiang Liu
>>>>> Reviewed-by: Wen Congyang
>>>>&g
Wrapper fucntion reserve_bootmem_generic() currently have no caller,
so clean it up.
Signed-off-by: Lin Feng
---
include/linux/bootmem.h |3 ---
mm/bootmem.c|6 --
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/include/linux/bootmem.h b/include/linux
Wrapper fucntion reserve_bootmem_generic() currently have no caller,
so clean it up.
Signed-off-by: Lin Feng linf...@cn.fujitsu.com
---
include/linux/bootmem.h |3 ---
mm/bootmem.c|6 --
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/include/linux
...@cn.fujitsu.com
Signed-off-by: Jiang Liu jiang@huawei.com
Reviewed-by: Wen Congyang we...@cn.fujitsu.com
Reviewed-by: Lai Jiangshan la...@cn.fujitsu.com
Tested-by: Lin Feng linf...@cn.fujitsu.com
---
mm/page_alloc.c | 77
+++
1 files changed, 77
On 11/30/2012 06:47 PM, Andrew Morton wrote:
> On Fri, 30 Nov 2012 18:29:30 +0800 Lin Feng wrote:
>
>>> add a new library function which callers can use before (or after?)
>>> calling get_user_pages[_fast]().
>> Sorry, I'm not quite understand what "library
On 11/30/2012 07:00 PM, Mel Gorman wrote:
>>
>> Well, that's a fairly low-level implementation detail. A more typical
>> approach would be to add a new get_user_pages_non_movable() or such.
>> That would probably have the same signature as get_user_pages(), with
>> one additional argument.
hi Domenico,
Sorry for my late reply and thanks for your attention, see below :)
On 11/30/2012 11:24 PM, Domenico Andreoli wrote:
> On Thu, Nov 29, 2012 at 02:54:58PM +0800, Lin Feng wrote:
>> Hi all,
>
> Hi Lin,
>
>> We encounter a "Resource temporarily u
hi Domenico,
Sorry for my late reply and thanks for your attention, see below :)
On 11/30/2012 11:24 PM, Domenico Andreoli wrote:
On Thu, Nov 29, 2012 at 02:54:58PM +0800, Lin Feng wrote:
Hi all,
Hi Lin,
We encounter a Resource temporarily unavailable fail while trying
to offline
On 11/30/2012 07:00 PM, Mel Gorman wrote:
Well, that's a fairly low-level implementation detail. A more typical
approach would be to add a new get_user_pages_non_movable() or such.
That would probably have the same signature as get_user_pages(), with
one additional argument. Then
On 11/30/2012 06:47 PM, Andrew Morton wrote:
On Fri, 30 Nov 2012 18:29:30 +0800 Lin Feng linf...@cn.fujitsu.com wrote:
add a new library function which callers can use before (or after?)
calling get_user_pages[_fast]().
Sorry, I'm not quite understand what library function function means
On 11/30/2012 03:55 PM, Andrew Morton wrote:
> On Fri, 30 Nov 2012 15:01:26 +0800 Lin Feng wrote:
>
>>
>>
>> On 11/30/2012 01:57 PM, Andrew Morton wrote:
>>> On Fri, 30 Nov 2012 11:42:05 +0800 Lin Feng wrote:
>>>
>>>> hi Andrew,
On 11/30/2012 03:55 PM, Andrew Morton wrote:
On Fri, 30 Nov 2012 15:01:26 +0800 Lin Feng linf...@cn.fujitsu.com wrote:
On 11/30/2012 01:57 PM, Andrew Morton wrote:
On Fri, 30 Nov 2012 11:42:05 +0800 Lin Feng linf...@cn.fujitsu.com wrote:
hi Andrew,
On 11/30/2012 07:39 AM, Andrew
On 11/30/2012 01:57 PM, Andrew Morton wrote:
> On Fri, 30 Nov 2012 11:42:05 +0800 Lin Feng wrote:
>
>> hi Andrew,
>>
>> On 11/30/2012 07:39 AM, Andrew Morton wrote:
>>> Tricky.
>>>
>>> I expect the same problem would occur with pages which ar
hi Andrew,
On 11/30/2012 07:39 AM, Andrew Morton wrote:
> Tricky.
>
> I expect the same problem would occur with pages which are under
> O_DIRECT I/O. Obviously O_DIRECT pages won't be pinned for such long
> periods, but the durations could still be lengthy (seconds).
the offline retry timeout
ng
> with non-movable pages to begin with. It's calling get_user_pages() a
> few lines after instantiating the mapping itself with do_mmap_pgoff().
>
> - z
>
--
------
Lin Feng
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FN
get_user_pages() a
few lines after instantiating the mapping itself with do_mmap_pgoff().
- z
--
--
Lin Feng
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) No. 6 Wenzhu Road,
Nanjing, 210012, China
PHONE：+86-25-86630566
hi Andrew,
On 11/30/2012 07:39 AM, Andrew Morton wrote:
Tricky.
I expect the same problem would occur with pages which are under
O_DIRECT I/O. Obviously O_DIRECT pages won't be pinned for such long
periods, but the durations could still be lengthy (seconds).
the offline retry timeout
On 11/30/2012 01:57 PM, Andrew Morton wrote:
On Fri, 30 Nov 2012 11:42:05 +0800 Lin Feng linf...@cn.fujitsu.com wrote:
hi Andrew,
On 11/30/2012 07:39 AM, Andrew Morton wrote:
Tricky.
I expect the same problem would occur with pages which are under
O_DIRECT I/O. Obviously O_DIRECT
Hi all,
We encounter a "Resource temporarily unavailable" fail while trying
to offline a memory section in a movable zone. We found that there are
some pages can't be migrated. The offline operation fails in function
migrate_page_move_mapping() returning -EAGAIN till timeout because
the if
Hi all,
We encounter a Resource temporarily unavailable fail while trying
to offline a memory section in a movable zone. We found that there are
some pages can't be migrated. The offline operation fails in function
migrate_page_move_mapping() returning -EAGAIN till timeout because
the if
101 - 190 of 190 matches
Mail list logo
