Hm. I'm not sure why this path series start [patch 4/10]. maybe I need to
review my script again.
anyway, patch 1-3 don't exist. sorry for confusing.
--
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
(4/27/13 12:40 AM), Olivier Langlois wrote:
>
>
> Forbids the cputimer to drift ahead of its process clock by
> blocking its update when a tick occurs while a autoreaping task
> is currently in do_exit() between the call to release_task() and
> its final call to schedule().
>
> Any task stats
(4/27/13 12:40 AM), Olivier Langlois wrote:
Forbids the cputimer to drift ahead of its process clock by
blocking its update when a tick occurs while a autoreaping task
is currently in do_exit() between the call to release_task() and
its final call to schedule().
Any task stats update
On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
wrote:
> On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
>> > I need to add that I can only confirm that to be true with
>> > sum_exec_runtime.
>> >
>> > To affirm it to be true for stime and utim
the patch accounting all the feedbacks that I
> received from KOSAKI Motohiro, Frederic Weisbecker and Peter Zijlstra
> and send it back here for further discussion.
>
> Thank you very much all!
Do you mean your utime test case still failure? If you share your test-case,
I'm going to look at
that I
received from KOSAKI Motohiro, Frederic Weisbecker and Peter Zijlstra
and send it back here for further discussion.
Thank you very much all!
Do you mean your utime test case still failure? If you share your test-case,
I'm going to look at your issue too.
--
To unsubscribe from
On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
oliv...@trillion01.com wrote:
On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
I need to add that I can only confirm that to be true with
sum_exec_runtime.
To affirm it to be true for stime and utime would require more
On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
wrote:
>> I feel we are hitting the same issue than this patch:
>> https://lkml.org/lkml/2013/4/5/116
>>
>> I'm adding Kosaki in Cc, who proposed roughly the same fix.
>
> Thanks to CCing. I'm now sitting LSF and
> I feel we are hitting the same issue than this patch:
> https://lkml.org/lkml/2013/4/5/116
>
> I'm adding Kosaki in Cc, who proposed roughly the same fix.
Thanks to CCing. I'm now sitting LSF and I can't read whole tons emails.
However the fix is definitely same and I definitely agree this
I feel we are hitting the same issue than this patch:
https://lkml.org/lkml/2013/4/5/116
I'm adding Kosaki in Cc, who proposed roughly the same fix.
Thanks to CCing. I'm now sitting LSF and I can't read whole tons emails.
However the fix is definitely same and I definitely agree this
On Fri, Apr 19, 2013 at 10:38 AM, KOSAKI Motohiro
kosaki.motoh...@gmail.com wrote:
I feel we are hitting the same issue than this patch:
https://lkml.org/lkml/2013/4/5/116
I'm adding Kosaki in Cc, who proposed roughly the same fix.
Thanks to CCing. I'm now sitting LSF and I can't read whole
> #ifdef CONFIG_HOTPLUG_CPU
> +static void change_cpu_under_node(struct cpu *cpu,
> + unsigned int from_nid, unsigned int to_nid)
> +{
> + int cpuid = cpu->dev.id;
> + unregister_cpu_under_node(cpuid, from_nid);
> + register_cpu_under_node(cpuid, to_nid);
>
#ifdef CONFIG_HOTPLUG_CPU
+static void change_cpu_under_node(struct cpu *cpu,
+ unsigned int from_nid, unsigned int to_nid)
+{
+ int cpuid = cpu-dev.id;
+ unregister_cpu_under_node(cpuid, from_nid);
+ register_cpu_under_node(cpuid, to_nid);
+
On Tue, Apr 16, 2013 at 3:07 PM, David Howells wrote:
>
> KOSAKI Motohiro wrote:
>
>> I have no seen any issue in this change. but why? Is there any
>> motivation rather than cleanup?
>
> Stopping stuff mucking about with the internals of procfs incorrectly
> (s
On Tue, Apr 16, 2013 at 11:26 AM, David Howells wrote:
> Split kcore bits from linux/procfs.h into linux/kcore.h.
>
> Signed-off-by: David Howells
> cc: linux-m...@linux-mips.org
> cc: sparcli...@vger.kernel.org
> cc: x...@kernel.org
> cc: linux...@kvack.org
I have no seen any issue in this
On Tue, Apr 16, 2013 at 11:26 AM, David Howells dhowe...@redhat.com wrote:
Split kcore bits from linux/procfs.h into linux/kcore.h.
Signed-off-by: David Howells dhowe...@redhat.com
cc: linux-m...@linux-mips.org
cc: sparcli...@vger.kernel.org
cc: x...@kernel.org
cc: linux...@kvack.org
I
On Tue, Apr 16, 2013 at 3:07 PM, David Howells dhowe...@redhat.com wrote:
KOSAKI Motohiro kosaki.motoh...@gmail.com wrote:
I have no seen any issue in this change. but why? Is there any
motivation rather than cleanup?
Stopping stuff mucking about with the internals of procfs incorrectly
(4/13/13 5:14 AM), Marco Stornelli wrote:
> Hi,
>
> I was seeing the code of __mm_populate (in -next) and I've got a doubt
> about the return value. The function __mlock_posix_error_return should
> return a proper error for mlock, converting the return value from
> __get_user_pages. It checks
(4/13/13 5:14 AM), Marco Stornelli wrote:
Hi,
I was seeing the code of __mm_populate (in -next) and I've got a doubt
about the return value. The function __mlock_posix_error_return should
return a proper error for mlock, converting the return value from
__get_user_pages. It checks for
(4/10/13 11:26 PM), Mitsuhiro Tanino wrote:
> Hi All,
> Please find a patch set that introduces these new sysctl interfaces,
> to handle a case when an memory error is detected on dirty page cache.
>
> - vm.memory_failure_dirty_panic
Panic knob is ok to me. However I agree with Andi. If we need
and adding new syscall invokation is unwelcome.
>>>
>>> Sure. But one more system call could be cheaper than page-granuarity
>>> operation on purged range.
>>
>> I don't think vrange(VOLATILE) cost is the related of this discusstion.
>> Whether sending SIGBUS or just nuke pte, purge should be
(4/11/13 4:02 AM), Minchan Kim wrote:
> On Thu, Apr 11, 2013 at 03:20:30AM -0400, KOSAKI Motohiro wrote:
>>>>> DONTNEED makes sure user always can see zero-fill pages after
>>>>> he calls madvise while vrange can see data or encounter SIGBUS.
>>>>
&
>>> DONTNEED makes sure user always can see zero-fill pages after
>>> he calls madvise while vrange can see data or encounter SIGBUS.
>>
>> For replacing DONTNEED, user want to zero-fill pages like DONTNEED
>> instead of SIGBUS. So, new flag option would be nice.
>
> If userspace people want
DONTNEED makes sure user always can see zero-fill pages after
he calls madvise while vrange can see data or encounter SIGBUS.
For replacing DONTNEED, user want to zero-fill pages like DONTNEED
instead of SIGBUS. So, new flag option would be nice.
If userspace people want it, I can do
(4/11/13 4:02 AM), Minchan Kim wrote:
On Thu, Apr 11, 2013 at 03:20:30AM -0400, KOSAKI Motohiro wrote:
DONTNEED makes sure user always can see zero-fill pages after
he calls madvise while vrange can see data or encounter SIGBUS.
For replacing DONTNEED, user want to zero-fill pages like
and adding new syscall invokation is unwelcome.
Sure. But one more system call could be cheaper than page-granuarity
operation on purged range.
I don't think vrange(VOLATILE) cost is the related of this discusstion.
Whether sending SIGBUS or just nuke pte, purge should be done on vmscan,
(4/10/13 11:26 PM), Mitsuhiro Tanino wrote:
Hi All,
Please find a patch set that introduces these new sysctl interfaces,
to handle a case when an memory error is detected on dirty page cache.
- vm.memory_failure_dirty_panic
Panic knob is ok to me. However I agree with Andi. If we need panic
oes
Looks good.
Acked-by: KOSAKI Motohiro
--
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/
>> I've never checked it but I would have expected kswapd to stay on the
>> same processor for significant periods of time. Have you experienced
>> problems where kswapd bounces around on CPUs within a node causing
>> workload disruption?
>
> When kswapd shares the same CPU as our main process it
> Signed-off-by: Naoya Horiguchi
> Reviewed-by: Rik van Riel
> Acked-by: Michal Hocko
> Reviewed-by: HATAYAMA Daisuke
> Acked-by: KOSAKI Motohiro
> Acked-by: David Rientjes
> Cc: [2.6.34+]
Not correct. It's 3.7 materials. See Michal or my comments.
cut
(3/12/13 3:38 AM), Minchan Kim wrote:
> First of all, let's define the term.
> From now on, I'd like to call it as vrange(a.k.a volatile range)
> for anonymous page. If you have a better name in mind, please suggest.
>
> This version is still *RFC* because it's just quick prototype so
> it
; for hwpoisoned ones.
>
> ChangeLog v5:
> - improve comment and description.
>
> ChangeLog v4:
> - move is_swap_page() to right place.
>
> ChangeLog v3:
> - add comment about using is_swap_pte()
>
> Signed-off-by: Naoya Horiguchi
> Cc: sta...@vger.kernel.org
Acked
.
ChangeLog v3:
- add comment about using is_swap_pte()
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Cc: sta...@vger.kernel.org
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
(3/12/13 3:38 AM), Minchan Kim wrote:
First of all, let's define the term.
From now on, I'd like to call it as vrange(a.k.a volatile range)
for anonymous page. If you have a better name in mind, please suggest.
This version is still *RFC* because it's just quick prototype so
it doesn't
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Reviewed-by: Rik van Riel r...@redhat.com
Acked-by: Michal Hocko mho...@suse.cz
Reviewed-by: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Acked-by: David Rientjes rient
I've never checked it but I would have expected kswapd to stay on the
same processor for significant periods of time. Have you experienced
problems where kswapd bounces around on CPUs within a node causing
workload disruption?
When kswapd shares the same CPU as our main process it causes a
Looks good.
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.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 the FAQ at http
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.
>> >
>>
> I rewrite the comment here, how about this?
>
> - if (absent ||
> + /*
> +* We need call hugetlb_fault for both hugepages under
> migration
> +* (in which case hugetlb_fault waits for the migration,) and
> +* hwpoisoned
>> 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
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
I rewrite the comment here, how about this?
- if (absent ||
+ /*
+* We need call hugetlb_fault for both hugepages under
migration
+* (in which case hugetlb_fault waits for the migration,) and
+* hwpoisoned
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
> This approach works on any task via it's proc, and can be used on different
> tasks in parallel.
>
> Also, Andrew was asking for some performance numbers related to the change.
> Now I can say, that as long as soft dirty bits are not cleared, no performance
> penalty occur, since the soft dirty
(4/8/13 3:50 PM), Cody P Schafer wrote:
> On 04/08/2013 10:28 AM, Cody P Schafer wrote:
>> On 04/08/2013 05:20 AM, Gilad Ben-Yossef wrote:
>>> On Fri, Apr 5, 2013 at 11:33 PM, Cody P Schafer
>>> wrote:
In free_hot_cold_page(), we rely on pcp->batch remaining stable.
Updating it without
(4/8/13 3:49 PM), Cody P Schafer wrote:
> On 04/08/2013 12:26 PM, KOSAKI Motohiro wrote:
>> (4/8/13 1:32 PM), Cody P Schafer wrote:
>>> On 04/07/2013 08:39 AM, KOSAKI Motohiro wrote:
>>>> (4/5/13 4:33 PM), Cody P Schafer wrote:
>>>>>
> - if (absent ||
> + /*
> +* is_swap_pte test covers both is_hugetlb_entry_hwpoisoned
> +* and hugepages under migration in which case
> +* hugetlb_fault waits for the migration and bails out
> +* properly
(4/8/13 1:32 PM), Cody P Schafer wrote:
> On 04/07/2013 08:39 AM, KOSAKI Motohiro wrote:
>> (4/5/13 4:33 PM), Cody P Schafer wrote:
>>> No off-cpu users of the percpu pagesets exist.
>>>
>>> zone_pcp_update()'s goal is to adjust the ->high and ->
(4/8/13 8:20 AM), Gilad Ben-Yossef wrote:
> On Fri, Apr 5, 2013 at 11:33 PM, Cody P Schafer
> wrote:
>> In free_hot_cold_page(), we rely on pcp->batch remaining stable.
>> Updating it without being on the cpu owning the percpu pageset
>> potentially destroys this stability.
>>
>> Change
(4/8/13 1:16 PM), Cody P Schafer wrote:
> On 04/07/2013 08:23 AM, KOSAKI Motohiro wrote:
>> (4/5/13 4:33 PM), Cody P Schafer wrote:
>>> In one case while modifying the ->high and ->batch fields of per cpu
>>> pagesets
>>> we're unneededly using stop_ma
(4/8/13 1:16 PM), Cody P Schafer wrote:
On 04/07/2013 08:23 AM, KOSAKI Motohiro wrote:
(4/5/13 4:33 PM), Cody P Schafer wrote:
In one case while modifying the -high and -batch fields of per cpu
pagesets
we're unneededly using stop_machine() (patches 1 2), and in another we
don't have any
(4/8/13 8:20 AM), Gilad Ben-Yossef wrote:
On Fri, Apr 5, 2013 at 11:33 PM, Cody P Schafer c...@linux.vnet.ibm.com
wrote:
In free_hot_cold_page(), we rely on pcp-batch remaining stable.
Updating it without being on the cpu owning the percpu pageset
potentially destroys this stability.
(4/8/13 1:32 PM), Cody P Schafer wrote:
On 04/07/2013 08:39 AM, KOSAKI Motohiro wrote:
(4/5/13 4:33 PM), Cody P Schafer wrote:
No off-cpu users of the percpu pagesets exist.
zone_pcp_update()'s goal is to adjust the -high and -mark members of a
percpu pageset based on a zone's -managed_pages
- if (absent ||
+ /*
+* is_swap_pte test covers both is_hugetlb_entry_hwpoisoned
+* and hugepages under migration in which case
+* hugetlb_fault waits for the migration and bails out
+* properly for
(4/8/13 3:49 PM), Cody P Schafer wrote:
On 04/08/2013 12:26 PM, KOSAKI Motohiro wrote:
(4/8/13 1:32 PM), Cody P Schafer wrote:
On 04/07/2013 08:39 AM, KOSAKI Motohiro wrote:
(4/5/13 4:33 PM), Cody P Schafer wrote:
No off-cpu users of the percpu pagesets exist.
zone_pcp_update()'s goal
(4/8/13 3:50 PM), Cody P Schafer wrote:
On 04/08/2013 10:28 AM, Cody P Schafer wrote:
On 04/08/2013 05:20 AM, Gilad Ben-Yossef wrote:
On Fri, Apr 5, 2013 at 11:33 PM, Cody P Schafer
c...@linux.vnet.ibm.com wrote:
In free_hot_cold_page(), we rely on pcp-batch remaining stable.
Updating it
This approach works on any task via it's proc, and can be used on different
tasks in parallel.
Also, Andrew was asking for some performance numbers related to the change.
Now I can say, that as long as soft dirty bits are not cleared, no performance
penalty occur, since the soft dirty bit
On Sun, Apr 7, 2013 at 11:27 PM, Chen Gang wrote:
>
> for NUL terminated string, always set '\0' at the end.
>
> Signed-off-by: Chen Gang
> ---
> kernel/tsacct.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/tsacct.c b/kernel/tsacct.c
> index
d-off-by: Cody P Schafer
Acked-by: KOSAKI Motohiro
--
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/
(4/5/13 4:33 PM), Cody P Schafer wrote:
> No off-cpu users of the percpu pagesets exist.
>
> zone_pcp_update()'s goal is to adjust the ->high and ->mark members of a
> percpu pageset based on a zone's ->managed_pages. We don't need to drain
> the entire percpu pageset just to modify these fields.
(4/5/13 4:33 PM), Cody P Schafer wrote:
> In one case while modifying the ->high and ->batch fields of per cpu pagesets
> we're unneededly using stop_machine() (patches 1 & 2), and in another we
> don't have any
> syncronization at all (patch 3).
>
> This patchset fixes both of them.
>
> Note
>> Please refer to hugetlb_fault for more information.
>
> Thanks for your pointing out. So my assume is correct, is it? Can pmd
> which support 2MB map 32MB pages work well?
Simon, Please stop hijaking unrelated threads. This is not question and answer
thread.
--
To unsubscribe from this
Please refer to hugetlb_fault for more information.
Thanks for your pointing out. So my assume is correct, is it? Can pmd
which support 2MB map 32MB pages work well?
Simon, Please stop hijaking unrelated threads. This is not question and answer
thread.
--
To unsubscribe from this list:
(4/5/13 4:33 PM), Cody P Schafer wrote:
In one case while modifying the -high and -batch fields of per cpu pagesets
we're unneededly using stop_machine() (patches 1 2), and in another we
don't have any
syncronization at all (patch 3).
This patchset fixes both of them.
Note that it
(4/5/13 4:33 PM), Cody P Schafer wrote:
No off-cpu users of the percpu pagesets exist.
zone_pcp_update()'s goal is to adjust the -high and -mark members of a
percpu pageset based on a zone's -managed_pages. We don't need to drain
the entire percpu pageset just to modify these fields. Avoid
...@linux.vnet.ibm.com
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.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 the FAQ at http
On Sun, Apr 7, 2013 at 11:27 PM, Chen Gang gang.c...@asianux.com wrote:
for NUL terminated string, always set '\0' at the end.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
kernel/tsacct.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/tsacct.c
On Sat, Apr 6, 2013 at 6:07 AM, Marco Stornelli
wrote:
> In case of VM_FAULT_RETRY, __get_user_pages returns the number
> of pages alredy gotten, but there isn't a check if this number is
> zero. Instead, we have to return a proper error code so we can avoid
> a possible extra call of
On Sat, Apr 6, 2013 at 6:07 AM, Marco Stornelli
marco.storne...@gmail.com wrote:
In case of VM_FAULT_RETRY, __get_user_pages returns the number
of pages alredy gotten, but there isn't a check if this number is
zero. Instead, we have to return a proper error code so we can avoid
a possible
(3/25/13 11:12 AM), Michal Hocko wrote:
> On Fri 22-03-13 16:23:55, Naoya Horiguchi wrote:
> [...]
>> @@ -2086,11 +2085,7 @@ int hugetlb_treat_movable_handler(struct ctl_table
>> *table, int write,
>> void __user *buffer,
>> size_t *length, loff_t *ppos)
(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.
>> -if (!new_hpage)
>> +/*
>> + * Getting a new hugepage with alloc_huge_page() (which can happen
>> + * when migration is caused by mbind()) can return ERR_PTR value,
>> + * so we need take care of the case here.
>> + */
>> +if (!new_hpage || IS_ERR_VALUE(new_hpage))
> @@ -1277,14 +1279,10 @@ static long do_mbind(unsigned long start, unsigned
> long len,
> if (!err) {
> int nr_failed = 0;
>
> - if (!list_empty()) {
> - WARN_ON_ONCE(flags & MPOL_MF_LAZY);
> - nr_failed = migrate_pages(,
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
> This patch extends check_range() to handle vma with VM_HUGETLB set.
> We will be able to migrate hugepage with migrate_pages(2) after
> applying the enablement patch which comes later in this series.
>
> Note that for larger hugepages (covered by pud
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
> Due to the previous patch, soft_offline_huge_page() switches to use
> migrate_pages(), and migrate_huge_page() is not used any more.
> So let's remove it.
>
> Signed-off-by: Naoya Horiguchi
Acked-by: KOSAKI Motohiro
--
To u
(3/27/13 9:00 AM), Michal Hocko wrote:
> On Tue 26-03-13 16:35:35, Naoya Horiguchi wrote:
> [...]
>> The differences is that migrate_huge_page() has one hugepage as an argument,
>> and migrate_pages() has a pagelist with multiple hugepages.
>> I already told this before and I'm not sure it's
>>> There doesn't seem to be any caller for this function. Please move it to
>>> the patch which uses it.
>>
>> I would do like that if there's only one user of this function, but I thought
>> that it's better to separate this part as changes of common code
>> because this function is commonly
> diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c
> index 0a0be33..98a478e 100644
> --- v3.9-rc3.orig/mm/hugetlb.c
> +++ v3.9-rc3/mm/hugetlb.c
> @@ -2819,7 +2819,7 @@ int hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
> if (ptep) {
> entry =
> diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c
> index 0a0be33..98a478e 100644
> --- v3.9-rc3.orig/mm/hugetlb.c
> +++ v3.9-rc3/mm/hugetlb.c
> @@ -2819,7 +2819,7 @@ int hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
> if (ptep) {
> entry =
checks of bit 0-4
> for vma(VM_HUGETLB). So this patch inserts 'return' and makes it work
> as written in the document.
>
> Signed-off-by: Naoya Horiguchi
> Cc: sta...@vger.kernel.org
If I were you, I merge this patch into [1/3] because both patches treat the same
regression. but it is
(4/3/13 2:35 PM), Naoya Horiguchi wrote:
> With applying the previous patch "hugetlbfs: stop setting VM_DONTDUMP in
> initializing vma(VM_HUGETLB)" to reenable hugepage coredump, if a memory
> error happens on a hugepage and the affected processes try to access
> the error hugepage, we hit
return 0;
Look, VM_NODUMP and VM_RESERVED had similar and different meanings at this time.
Finally, Konstantin removed VM_RESERVED and hugetlb coredump behavior
has been changed.
Thus, patch [1/3] and [2/3] should be marked [stable for v3.6 or later].
Anyway, this patch is correct. Thank yo
From: KOSAKI Motohiro
Currently glibc rt/cpuclock2 test(*) sporadically fail. The
pseudo test code is here.
t0 = clock_gettime()
abs = t0 + sleeptime;
clock_nanosleep(TIMER_ABSTIME, abs)
t1 = clock_gettime()
assert(t1-t0 > sleeptime)
assert(t1 > abs)
Because current signal->
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently glibc rt/cpuclock2 test(*) sporadically fail. The
pseudo test code is here.
t0 = clock_gettime()
abs = t0 + sleeptime;
clock_nanosleep(TIMER_ABSTIME, abs)
t1 = clock_gettime()
assert(t1-t0 sleeptime)
assert(t1 abs)
Because
, Konstantin removed VM_RESERVED and hugetlb coredump behavior
has been changed.
Thus, patch [1/3] and [2/3] should be marked [stable for v3.6 or later].
Anyway, this patch is correct. Thank you!
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
To unsubscribe from this list: send
(4/3/13 2:35 PM), Naoya Horiguchi wrote:
With applying the previous patch hugetlbfs: stop setting VM_DONTDUMP in
initializing vma(VM_HUGETLB) to reenable hugepage coredump, if a memory
error happens on a hugepage and the affected processes try to access
the error hugepage, we hit
.
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.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 the FAQ at http://www.tux.org/lkml/
diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c
index 0a0be33..98a478e 100644
--- v3.9-rc3.orig/mm/hugetlb.c
+++ v3.9-rc3/mm/hugetlb.c
@@ -2819,7 +2819,7 @@ int hugetlb_fault(struct mm_struct *mm, struct
vm_area_struct *vma,
if (ptep) {
entry =
diff --git v3.9-rc3.orig/mm/hugetlb.c v3.9-rc3/mm/hugetlb.c
index 0a0be33..98a478e 100644
--- v3.9-rc3.orig/mm/hugetlb.c
+++ v3.9-rc3/mm/hugetlb.c
@@ -2819,7 +2819,7 @@ int hugetlb_fault(struct mm_struct *mm, struct
vm_area_struct *vma,
if (ptep) {
entry =
There doesn't seem to be any caller for this function. Please move it to
the patch which uses it.
I would do like that if there's only one user of this function, but I thought
that it's better to separate this part as changes of common code
because this function is commonly used by multiple
(3/27/13 9:00 AM), Michal Hocko wrote:
On Tue 26-03-13 16:35:35, Naoya Horiguchi wrote:
[...]
The differences is that migrate_huge_page() has one hugepage as an argument,
and migrate_pages() has a pagelist with multiple hugepages.
I already told this before and I'm not sure it's enough to
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
Due to the previous patch, soft_offline_huge_page() switches to use
migrate_pages(), and migrate_huge_page() is not used any more.
So let's remove it.
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Acked-by: KOSAKI Motohiro kosaki.motoh
(3/22/13 4:23 PM), Naoya Horiguchi wrote:
This patch extends check_range() to handle vma with VM_HUGETLB set.
We will be able to migrate hugepage with migrate_pages(2) after
applying the enablement patch which comes later in this series.
Note that for larger hugepages (covered by pud
@@ -1277,14 +1279,10 @@ static long do_mbind(unsigned long start, unsigned
long len,
if (!err) {
int nr_failed = 0;
- if (!list_empty(pagelist)) {
- WARN_ON_ONCE(flags MPOL_MF_LAZY);
- nr_failed =
-if (!new_hpage)
+/*
+ * Getting a new hugepage with alloc_huge_page() (which can happen
+ * when migration is caused by mbind()) can return ERR_PTR value,
+ * so we need take care of the case here.
+ */
+if (!new_hpage || IS_ERR_VALUE(new_hpage))
(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/25/13 11:12 AM), Michal Hocko wrote:
On Fri 22-03-13 16:23:55, Naoya Horiguchi wrote:
[...]
@@ -2086,11 +2085,7 @@ int hugetlb_treat_movable_handler(struct ctl_table
*table, int write,
void __user *buffer,
size_t *length, loff_t *ppos)
{
-
> --- linux.orig/mm/page_alloc.c 2013-03-19 16:09:03.736450861 -0500
> +++ linux/mm/page_alloc.c 2013-03-22 17:07:43.895405617 -0500
> @@ -4161,10 +4161,23 @@ int __meminit __early_pfn_to_nid(unsigne
> {
> unsigned long start_pfn, end_pfn;
> int i, nid;
> + /*
> +
--- linux.orig/mm/page_alloc.c 2013-03-19 16:09:03.736450861 -0500
+++ linux/mm/page_alloc.c 2013-03-22 17:07:43.895405617 -0500
@@ -4161,10 +4161,23 @@ int __meminit __early_pfn_to_nid(unsigne
{
unsigned long start_pfn, end_pfn;
int i, nid;
+ /*
+
On Thu, Feb 28, 2013 at 1:53 AM, Hillf Danton wrote:
> On Thu, Feb 28, 2013 at 1:26 PM, KOSAKI Motohiro
> wrote:
>>> Insert new node after updating node in tree.
>>
>> Thanks. you are right. I could reproduce and verified.
>
> Thank you too;) pleasure to do minor
401 - 500 of 949 matches
Mail list logo
