(11/1/13 3:54 AM), Yuanhan Liu wrote:
Patch 1 turns locking the anon_vma's root to locking itself to let it be
a per anon_vma lock, which would reduce contentions.
In the same time, lock range becomes quite small then, which is bascially
a call of anon_vma_interval_tree_insert(). Patch 2
(11/1/13 4:17 PM), Davidlohr Bueso wrote:
While caching the last used vma already does a nice job avoiding
having to iterate the rbtree in find_vma, we can improve. After
studying the hit rate on a load of workloads and environments,
it was seen that it was around 45-50% - constant for a
From: KOSAKI Motohiro
When __rmqueue_fallback() don't find out a free block with the same size
of required, it splits a larger page and puts back rest peiece of the page
to free list.
But it has one serious mistake. When putting back, __rmqueue_fallback()
always use start_migratetype if type
Nit. I would like to add following hunk. This is just nit because moving
reserve pageblock is extreme rare.
if (block_migratetype == MIGRATE_RESERVE) {
+ found++;
set_pageblock_migratetype(page, MIGRATE_MOVABLE);
Nit. I would like to add following hunk. This is just nit because moving
reserve pageblock is extreme rare.
if (block_migratetype == MIGRATE_RESERVE) {
+ found++;
set_pageblock_migratetype(page, MIGRATE_MOVABLE);
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
When __rmqueue_fallback() don't find out a free block with the same size
of required, it splits a larger page and puts back rest peiece of the page
to free list.
But it has one serious mistake. When putting back, __rmqueue_fallback()
always
(10/31/13 12:24 AM), kosaki.motoh...@gmail.com wrote:
> From: KOSAKI Motohiro
>
> When __rmqueue_fallback() don't find out a free block with the same size
> of required, it splits a larger page and puts back rest peiece of the page
> to free list.
>
> But it has one
(10/31/13 12:35 AM), Andrew Morton wrote:
On Thu, 31 Oct 2013 00:24:49 -0400 kosaki.motoh...@gmail.com wrote:
When __rmqueue_fallback() don't find out a free block with the same size
of required, it splits a larger page and puts back rest peiece of the page
to free list.
But it has one
such information on my long oom debugging history.
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 FA
From: KOSAKI Motohiro
When __rmqueue_fallback() don't find out a free block with the same size
of required, it splits a larger page and puts back rest peiece of the page
to free list.
But it has one serious mistake. When putting back, __rmqueue_fallback()
always use start_migratetype if type
@@ -3926,11 +3929,11 @@ static void setup_zone_migrate_reserve(struct zone
*zone)
/*
* Reserve blocks are generally in place to help high-order atomic
* allocations that are short-lived. A min_free_kbytes value that
-* would result in more than 2 reserve blocks
(10/30/13 11:19 AM), Mel Gorman wrote:
On Wed, Oct 23, 2013 at 05:01:32PM -0400, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro
Yasuaki Ithimatsu reported memory hot-add spent more than 5 _hours_
on 9TB memory machine and we found out setup_zone_migrate_reserve
spnet >90% t
(10/30/13 11:19 AM), Mel Gorman wrote:
On Wed, Oct 23, 2013 at 05:01:32PM -0400, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Yasuaki Ithimatsu reported memory hot-add spent more than 5 _hours_
on 9TB memory machine and we found out
@@ -3926,11 +3929,11 @@ static void setup_zone_migrate_reserve(struct zone
*zone)
/*
* Reserve blocks are generally in place to help high-order atomic
* allocations that are short-lived. A min_free_kbytes value that
-* would result in more than 2 reserve blocks
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
When __rmqueue_fallback() don't find out a free block with the same size
of required, it splits a larger page and puts back rest peiece of the page
to free list.
But it has one serious mistake. When putting back, __rmqueue_fallback()
always
used such information on my long oom debugging history.
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
(10/31/13 12:35 AM), Andrew Morton wrote:
On Thu, 31 Oct 2013 00:24:49 -0400 kosaki.motoh...@gmail.com wrote:
When __rmqueue_fallback() don't find out a free block with the same size
of required, it splits a larger page and puts back rest peiece of the page
to free list.
But it has one
(10/31/13 12:24 AM), kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
When __rmqueue_fallback() don't find out a free block with the same size
of required, it splits a larger page and puts back rest peiece of the page
to free list.
But it has one
> The concern is likely/unlikely usage is proper in this code peice.
> If we don't use memory isolation, the code path is used for only
> MIGRATE_RESERVE which is very rare allocation in normal workload.
>
> Even, in memory isolation environement, I'm not sure how many
> CMA/HOTPLUG is used
The concern is likely/unlikely usage is proper in this code peice.
If we don't use memory isolation, the code path is used for only
MIGRATE_RESERVE which is very rare allocation in normal workload.
Even, in memory isolation environement, I'm not sure how many
CMA/HOTPLUG is used compared to
From: KOSAKI Motohiro
Currently, set_pageblock_migratetype screw up MIGRATE_CMA and
MIGRATE_ISOLATE if page_group_by_mobility_disabled is true. It
rewrite the argument to MIGRATE_UNMOVABLE and we lost these attribute.
The problem was introduced commit 49255c619f (page allocator: move
check
From: KOSAKI Motohiro
In general, every tracepoint should be zero overhead if it is disabled.
However, trace_mm_page_alloc_extfrag() is one of exception. It evaluate
"new_type == start_migratetype" even if tracepoint is disabled.
However, the code can be moved into tracepoint's TP_f
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
In general, every tracepoint should be zero overhead if it is disabled.
However, trace_mm_page_alloc_extfrag() is one of exception. It evaluate
new_type == start_migratetype even if tracepoint is disabled.
However, the code can be moved
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently, set_pageblock_migratetype screw up MIGRATE_CMA and
MIGRATE_ISOLATE if page_group_by_mobility_disabled is true. It
rewrite the argument to MIGRATE_UNMOVABLE and we lost these attribute.
The problem was introduced commit 49255c619f
From: KOSAKI Motohiro
Yasuaki Ithimatsu reported memory hot-add spent more than 5 _hours_
on 9TB memory machine and we found out setup_zone_migrate_reserve
spnet >90% time.
The problem is, setup_zone_migrate_reserve scan all pageblock
unconditionally, but it is only necessary number of reser
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Yasuaki Ithimatsu reported memory hot-add spent more than 5 _hours_
on 9TB memory machine and we found out setup_zone_migrate_reserve
spnet 90% time.
The problem is, setup_zone_migrate_reserve scan all pageblock
unconditionally, but it is only
On 10/18/2013 6:39 PM, John Stultz wrote:
> On 10/17/2013 06:12 PM, KOSAKI Motohiro wrote:
>> (10/17/13 1:05 PM), John Stultz wrote:
>>> On 10/14/2013 02:33 PM, kosaki.motoh...@gmail.com wrote:
>>>> From: KOSAKI Motohiro
>>>>
>>>> Fedora Ruby
On 10/18/2013 6:39 PM, John Stultz wrote:
On 10/17/2013 06:12 PM, KOSAKI Motohiro wrote:
(10/17/13 1:05 PM), John Stultz wrote:
On 10/14/2013 02:33 PM, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Fedora Ruby maintainer reported latest Ruby doesn't
(10/17/13 1:05 PM), John Stultz wrote:
On 10/14/2013 02:33 PM, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro
Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora Rawhide
on ARM. (http://bugs.ruby-lang.org/issues/9008)
Because of, commit 1c6b39ad3f (alarmtimers: Return
(10/17/13 1:05 PM), John Stultz wrote:
On 10/14/2013 02:33 PM, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora Rawhide
on ARM. (http://bugs.ruby-lang.org/issues/9008)
Because of, commit
From: KOSAKI Motohiro
Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora Rawhide
on ARM. (http://bugs.ruby-lang.org/issues/9008)
Because of, commit 1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no
RTC device is present) intruduced to return ENOTSUPP when
clock_get{time,res} can't
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora Rawhide
on ARM. (http://bugs.ruby-lang.org/issues/9008)
Because of, commit 1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no
RTC device is present) intruduced to return ENOTSUPP
(10/7/13 11:07 PM), Minchan Kim wrote:
Hi KOSAKI,
On Mon, Oct 07, 2013 at 10:51:18PM -0400, KOSAKI Motohiro wrote:
Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS,
, );
Another reason to make it hard is that madvise(2) is tight coupled with
with vmas split/merge
Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS,
, );
Another reason to make it hard is that madvise(2) is tight coupled with
with vmas split/merge. It needs mmap_sem's write-side lock and it hurt
anon-vrange test performance much heavily and userland might want to
(10/7/13 4:55 PM), Jan Kara wrote:
On Thu 03-10-13 18:40:06, KOSAKI Motohiro wrote:
(10/2/13 3:36 PM), Jan Kara wrote:
On Wed 02-10-13 12:32:33, KOSAKI Motohiro wrote:
(10/2/13 10:27 AM), Jan Kara wrote:
Signed-off-by: Jan Kara
---
mm/process_vm_access.c | 8 ++--
1 file changed, 2
(10/7/13 4:55 PM), Jan Kara wrote:
On Thu 03-10-13 18:40:06, KOSAKI Motohiro wrote:
(10/2/13 3:36 PM), Jan Kara wrote:
On Wed 02-10-13 12:32:33, KOSAKI Motohiro wrote:
(10/2/13 10:27 AM), Jan Kara wrote:
Signed-off-by: Jan Kara j...@suse.cz
---
mm/process_vm_access.c | 8 ++--
1
Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS,
purged, ret);
Another reason to make it hard is that madvise(2) is tight coupled with
with vmas split/merge. It needs mmap_sem's write-side lock and it hurt
anon-vrange test performance much heavily and userland
(10/7/13 11:07 PM), Minchan Kim wrote:
Hi KOSAKI,
On Mon, Oct 07, 2013 at 10:51:18PM -0400, KOSAKI Motohiro wrote:
Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS,
purged, ret);
Another reason to make it hard is that madvise(2) is tight coupled with
with vmas
(10/2/13 3:36 PM), Jan Kara wrote:
On Wed 02-10-13 12:32:33, KOSAKI Motohiro wrote:
(10/2/13 10:27 AM), Jan Kara wrote:
Signed-off-by: Jan Kara
---
mm/process_vm_access.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/mm/process_vm_access.c b/mm
(10/2/13 3:36 PM), Jan Kara wrote:
On Wed 02-10-13 12:32:33, KOSAKI Motohiro wrote:
(10/2/13 10:27 AM), Jan Kara wrote:
Signed-off-by: Jan Kara j...@suse.cz
---
mm/process_vm_access.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/mm/process_vm_access.c b/mm
(10/2/13 10:27 AM), Jan Kara wrote:
> Signed-off-by: Jan Kara
> ---
> mm/process_vm_access.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
> index fd26d0433509..c1bc47d8ed90 100644
> ---
(10/2/13 10:27 AM), Jan Kara wrote:
> Provide a wrapper for get_user_pages() which takes care of acquiring and
> releasing mmap_sem. Using this function reduces amount of places in
> which we deal with mmap_sem.
>
> Signed-off-by: Jan Kara
> ---
> include/linux/mm.h | 14 ++
> 1
(10/2/13 10:27 AM), Jan Kara wrote:
Provide a wrapper for get_user_pages() which takes care of acquiring and
releasing mmap_sem. Using this function reduces amount of places in
which we deal with mmap_sem.
Signed-off-by: Jan Kara j...@suse.cz
---
include/linux/mm.h | 14 ++
(10/2/13 10:27 AM), Jan Kara wrote:
Signed-off-by: Jan Kara j...@suse.cz
---
mm/process_vm_access.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
index fd26d0433509..c1bc47d8ed90 100644
---
(10/1/13 7:31 PM), David Rientjes wrote:
for_each_online_cpu() needs the protection of {get,put}_online_cpus() so
cpu_online_mask doesn't change during the iteration.
Signed-off-by: David Rientjes
Acked-by: KOSAKI Motohiro
--
To unsubscribe from this list: send the line "unsubscribe
> +static void seq_print_vma_name(struct seq_file *m, struct vm_area_struct
> *vma)
> +{
> + const char __user *name = vma_get_anon_name(vma);
> + struct mm_struct *mm = vma->vm_mm;
> +
> + unsigned long page_start_vaddr;
> + unsigned long page_offset;
> + unsigned long
+static void seq_print_vma_name(struct seq_file *m, struct vm_area_struct
*vma)
+{
+ const char __user *name = vma_get_anon_name(vma);
+ struct mm_struct *mm = vma-vm_mm;
+
+ unsigned long page_start_vaddr;
+ unsigned long page_offset;
+ unsigned long num_pages;
+
(10/1/13 7:31 PM), David Rientjes wrote:
for_each_online_cpu() needs the protection of {get,put}_online_cpus() so
cpu_online_mask doesn't change during the iteration.
Signed-off-by: David Rientjes rient...@google.com
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
To unsubscribe
On Mon, Sep 16, 2013 at 8:18 PM, Wanpeng Li wrote:
> Hi KOSAKI,
> On Mon, Sep 16, 2013 at 05:23:32PM -0400, KOSAKI Motohiro wrote:
>>On 9/14/2013 7:45 PM, Wanpeng Li wrote:
>>> Changelog:
>>> *v2 -> v3: revert commit d157a558 directly
>>>
>>
On Mon, Sep 16, 2013 at 7:41 PM, Wanpeng Li wrote:
> Hi KOSAKI,
> On Mon, Sep 16, 2013 at 04:15:29PM -0400, KOSAKI Motohiro wrote:
>>On 9/14/2013 7:45 PM, Wanpeng Li wrote:
>>> Changelog:
>>> *v2 -> v3: revert commit 46c001a2 directly
>>>
>
On 9/14/2013 7:45 PM, Wanpeng Li wrote:
> Changelog:
> *v2 -> v3: revert commit d157a558 directly
>
> The VM_UNINITIALIZED/VM_UNLIST flag introduced by commit f5252e00(mm: avoid
> null pointer access in vm_struct via /proc/vmallocinfo) is used to avoid
> accessing the pages field with
On 9/14/2013 7:45 PM, Wanpeng Li wrote:
> Changelog:
> *v2 -> v3: revert commit 46c001a2 directly
>
> Don't warning twice in __vmalloc_area_node and __vmalloc_node_range if
> __vmalloc_area_node allocation failure. This patch revert commit 46c001a2
> (mm/vmalloc.c: emit the failure message
On 9/14/2013 7:45 PM, Wanpeng Li wrote:
> Changelog:
> *v1 -> v2: rebase against mmotm tree
>
> The caller address has already been set in set_vmalloc_vm(), there's no need
setup_vmalloc_vm()
> to set it again in __vmalloc_area_node.
>
>
> down in race window mentioned above. This patch fix it by don't dump any
> information for !VM_VM_AREA case and also remove (VM_LAZY_FREE |
> VM_LAZY_FREEING)
> check since they are not possible for !VM_VM_AREA case.
>
> Suggested-by: Joonsoo Kim
> Signed-off-by: Wanpeng Li
A
(9/16/13 8:53 AM), Jianguo Wu wrote:
Use more appropriate NUMA_NO_NODE instead of -1
Signed-off-by: Jianguo Wu
---
mm/mempolicy.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
I think this patch don't make any functional change, right?
Acked-by: KOSAKI Motohiro
-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/
for !VM_VM_AREA case.
Suggested-by: Joonsoo Kim iamjoonsoo@lge.com
Signed-off-by: Wanpeng Li liw...@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
On 9/14/2013 7:45 PM, Wanpeng Li wrote:
Changelog:
*v1 - v2: rebase against mmotm tree
The caller address has already been set in set_vmalloc_vm(), there's no need
setup_vmalloc_vm()
to set it again in __vmalloc_area_node.
Reviewed-by: Zhang
On 9/14/2013 7:45 PM, Wanpeng Li wrote:
Changelog:
*v2 - v3: revert commit 46c001a2 directly
Don't warning twice in __vmalloc_area_node and __vmalloc_node_range if
__vmalloc_area_node allocation failure. This patch revert commit 46c001a2
(mm/vmalloc.c: emit the failure message before
On 9/14/2013 7:45 PM, Wanpeng Li wrote:
Changelog:
*v2 - v3: revert commit d157a558 directly
The VM_UNINITIALIZED/VM_UNLIST flag introduced by commit f5252e00(mm: avoid
null pointer access in vm_struct via /proc/vmallocinfo) is used to avoid
accessing the pages field with unallocated page
On Mon, Sep 16, 2013 at 7:41 PM, Wanpeng Li liw...@linux.vnet.ibm.com wrote:
Hi KOSAKI,
On Mon, Sep 16, 2013 at 04:15:29PM -0400, KOSAKI Motohiro wrote:
On 9/14/2013 7:45 PM, Wanpeng Li wrote:
Changelog:
*v2 - v3: revert commit 46c001a2 directly
Don't warning twice in __vmalloc_area_node
On Mon, Sep 16, 2013 at 8:18 PM, Wanpeng Li liw...@linux.vnet.ibm.com wrote:
Hi KOSAKI,
On Mon, Sep 16, 2013 at 05:23:32PM -0400, KOSAKI Motohiro wrote:
On 9/14/2013 7:45 PM, Wanpeng Li wrote:
Changelog:
*v2 - v3: revert commit d157a558 directly
The VM_UNINITIALIZED/VM_UNLIST flag
On 9/12/2013 12:45 AM, Suzuki K. Poulose wrote:
> On 09/12/2013 12:57 AM, KOSAKI Motohiro wrote:
>> (9/3/13 4:39 AM), Janani Venkataraman wrote:
>>> Hello,
>>>
>>> We are working on an infrastructure to create a system core file of a
>>> specific
>
On 9/12/2013 12:45 AM, Suzuki K. Poulose wrote:
On 09/12/2013 12:57 AM, KOSAKI Motohiro wrote:
(9/3/13 4:39 AM), Janani Venkataraman wrote:
Hello,
We are working on an infrastructure to create a system core file of a
specific
process at run-time, non-disruptively. It can also be extended
vma->vm_end,
+flags & VM_READ ? 'r' : '-',
+flags & VM_WRITE ? 'w' : '-',
+flags & VM_EXEC ? 'x' : '-',
+flags & VM_MAYSHARE ?
+flags &
(9/3/13 4:39 AM), Janani Venkataraman wrote:
Hello,
We are working on an infrastructure to create a system core file of a specific
process at run-time, non-disruptively. It can also be extended to a case where
a process is able to take a self-core dump.
gcore, an existing utility creates a
(9/3/13 4:39 AM), Janani Venkataraman wrote:
Hello,
We are working on an infrastructure to create a system core file of a specific
process at run-time, non-disruptively. It can also be extended to a case where
a process is able to take a self-core dump.
gcore, an existing utility creates a
' : 's' : 'p',
+pgoff,
+MAJOR(dev), MINOR(dev), ino);
if (file) {
pad_len_spaces(m, len);
ack for mm parts.
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
To unsubscribe from this list: send the line unsubscribe
>> Hmm. I can do that, but wouldn't that make CONFIG_PREEMPT_VOLUNTARY
>> mostly equivalent to CONFIG_PREEMPT_NONE?
>
> According the the Kconfig help, PREEMPT_VOLUNTARY is about the
> *explicit* preemption points. And we do have a lot of them in
> "might_sleep()".
>
> And personally, I think it
Hmm. I can do that, but wouldn't that make CONFIG_PREEMPT_VOLUNTARY
mostly equivalent to CONFIG_PREEMPT_NONE?
According the the Kconfig help, PREEMPT_VOLUNTARY is about the
*explicit* preemption points. And we do have a lot of them in
might_sleep().
And personally, I think it makes a *lot*
This patch removes the use of stop_machine() in try_offline_node() and
adds comments to try_offline_node() and remove_memory() that
lock_device_hotplug() is required.
This patch need more verbose explanation. check_cpu_on_node() traverse cpus
and cpu hotplug seems to use
This patch removes the use of stop_machine() in try_offline_node() and
adds comments to try_offline_node() and remove_memory() that
lock_device_hotplug() is required.
This patch need more verbose explanation. check_cpu_on_node() traverse cpus
and cpu hotplug seems to use
(8/14/13 9:33 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 09:21:33PM -0400, Tejun Heo wrote:
Secondly, memory hotplug is now maintained I and kamezawa-san. Then, I much
likely
have a chance to get a hotplug related bug report. For protecting my life, I
don't
want get a false bug claim.
(8/14/13 9:21 PM), Tejun Heo wrote:
Hello, KOSAKI.
On Wed, Aug 14, 2013 at 09:08:22PM -0400, KOSAKI Motohiro wrote:
...
a fallback. Bogus and misguided fallback give a user false relief and they don't
notice their mistake quickly. The answer is, there is the fundamental rule.
We always said
(8/12/13 3:34 PM), Toshi Kani wrote:
> lock_device_hotplug() serializes hotplug & online/offline operations.
> The lock is held in common sysfs online/offline interfaces and ACPI
> hotplug code paths.
>
> try_offline_node() off-lines a node if all memory sections and cpus
> are removed on the
(8/14/13 5:36 PM), Tejun Heo wrote:
> On Wed, Aug 14, 2013 at 05:17:23PM -0400, KOSAKI Motohiro wrote:
>> You haven't explain practical benefit of your opinion. As far as users have
>> no benefit, I'm never agree. Sorry.
>
> Umm... how about being more robust and actu
(8/14/13 4:35 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 04:29:05PM -0400, KOSAKI Motohiro wrote:
Because boot failure have no chance to overlook and better way for practice.
That's an extremely poor excuse. We favor WARNs over BUGs for good
reasons. If a sysadmin cares about hotplug
(8/14/13 3:55 PM), Tejun Heo wrote:
Hello,
On Wed, Aug 14, 2013 at 03:40:31PM -0400, KOSAKI Motohiro wrote:
I don't agree it. Please look at other kernel options. A lot of these don't
follow you. These behave as direction, not advise.
I mean the fallback should be implemented at turning
(8/14/13 2:23 PM), Tejun Heo wrote:
Hello,
On Wed, Aug 14, 2013 at 02:15:44PM -0400, KOSAKI Motohiro wrote:
I don't follow this. We need to think why memory hotplug is necessary.
Because system reboot is unacceptable on several critical services. Then,
if someone set wrong boot option, systems
(8/12/13 1:23 PM), H. Peter Anvin wrote:
On 08/12/2013 10:01 AM, Tang Chen wrote:
I'm just thinking of a more extreme case. For example, if a machine
has only one node hotpluggable, and the kernel resides in that node.
Then the system has no hotpluggable node.
Yeah, sure, then there's no
(8/12/13 2:07 PM), Tejun Heo wrote:
Hey,
On Tue, Aug 13, 2013 at 01:01:09AM +0800, Tang Chen wrote:
Sorry for the misunderstanding.
I was trying to answer your question: "Why can't the kenrel allocate
hotpluggable memory opportunistic ?".
I've used the wrong word, I was meaning best-effort,
(8/12/13 2:07 PM), Tejun Heo wrote:
Hey,
On Tue, Aug 13, 2013 at 01:01:09AM +0800, Tang Chen wrote:
Sorry for the misunderstanding.
I was trying to answer your question: Why can't the kenrel allocate
hotpluggable memory opportunistic ?.
I've used the wrong word, I was meaning best-effort,
(8/12/13 1:23 PM), H. Peter Anvin wrote:
On 08/12/2013 10:01 AM, Tang Chen wrote:
I'm just thinking of a more extreme case. For example, if a machine
has only one node hotpluggable, and the kernel resides in that node.
Then the system has no hotpluggable node.
Yeah, sure, then there's no
(8/14/13 2:23 PM), Tejun Heo wrote:
Hello,
On Wed, Aug 14, 2013 at 02:15:44PM -0400, KOSAKI Motohiro wrote:
I don't follow this. We need to think why memory hotplug is necessary.
Because system reboot is unacceptable on several critical services. Then,
if someone set wrong boot option, systems
(8/14/13 3:55 PM), Tejun Heo wrote:
Hello,
On Wed, Aug 14, 2013 at 03:40:31PM -0400, KOSAKI Motohiro wrote:
I don't agree it. Please look at other kernel options. A lot of these don't
follow you. These behave as direction, not advise.
I mean the fallback should be implemented at turning
(8/14/13 4:35 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 04:29:05PM -0400, KOSAKI Motohiro wrote:
Because boot failure have no chance to overlook and better way for practice.
That's an extremely poor excuse. We favor WARNs over BUGs for good
reasons. If a sysadmin cares about hotplug
(8/14/13 5:36 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 05:17:23PM -0400, KOSAKI Motohiro wrote:
You haven't explain practical benefit of your opinion. As far as users have
no benefit, I'm never agree. Sorry.
Umm... how about being more robust and actually useable to begin with?
What's
(8/12/13 3:34 PM), Toshi Kani wrote:
lock_device_hotplug() serializes hotplug online/offline operations.
The lock is held in common sysfs online/offline interfaces and ACPI
hotplug code paths.
try_offline_node() off-lines a node if all memory sections and cpus
are removed on the node. It
(8/14/13 9:21 PM), Tejun Heo wrote:
Hello, KOSAKI.
On Wed, Aug 14, 2013 at 09:08:22PM -0400, KOSAKI Motohiro wrote:
...
a fallback. Bogus and misguided fallback give a user false relief and they don't
notice their mistake quickly. The answer is, there is the fundamental rule.
We always said
(8/14/13 9:33 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 09:21:33PM -0400, Tejun Heo wrote:
Secondly, memory hotplug is now maintained I and kamezawa-san. Then, I much
likely
have a chance to get a hotplug related bug report. For protecting my life, I
don't
want get a false bug claim.
is the size of buffer,
> it is a mistake to compare pos and len in add_to_pagemap() for checking
> buffer is full or not, and this can lead to buffer overflow and random
> kernel panic issue.
>
> Correct len to be total number of PM_ENTRY_BYTES in buffer.
>
> Signed-off-by: Yon
-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/
Note that remove_memory() has
> to use BUG_ON() since this function cannot fail.
>
> Signed-off-by: Toshi Kani
> ---
> mm/memory_hotplug.c | 22 ++
memory_hotplug.c is maintained by me and kamezawa-san. Please cc us
if you have a subsequent patch.
Acked-by: KOSA
() since this function cannot fail.
Signed-off-by: Toshi Kani toshi.k...@hp.com
---
mm/memory_hotplug.c | 22 ++
memory_hotplug.c is maintained by me and kamezawa-san. Please cc us
if you have a subsequent patch.
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko wrote:
> On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
>> >>> You missed the "!". I'm proposing that setting the new bit 2 will
>> >>> permit people to prevent the new printk if it is causing them proble
On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko mho...@suse.cz wrote:
On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
You missed the !. I'm proposing that setting the new bit 2 will
permit people to prevent the new printk if it is causing them problems.
No I don't. I'm sure almost all
On Thu, Aug 1, 2013 at 4:36 AM, Rich Felker wrote:
> On Thu, Aug 01, 2013 at 01:29:51AM -0700, Christoph Hellwig wrote:
>> Btw, FreeBSD has an extension to shm_open to create unnamed but fd
>> passable segments. From their man page:
>>
>> As a FreeBSD extension, the constant SHM_ANON may be
>>> You missed the "!". I'm proposing that setting the new bit 2 will
>>> permit people to prevent the new printk if it is causing them problems.
>>
>> No I don't. I'm sure almost all abuse users think our usage is correct. Then,
>> I can imagine all crazy applications start to use this flag
You missed the !. I'm proposing that setting the new bit 2 will
permit people to prevent the new printk if it is causing them problems.
No I don't. I'm sure almost all abuse users think our usage is correct. Then,
I can imagine all crazy applications start to use this flag eventually.
I
On Thu, Aug 1, 2013 at 4:36 AM, Rich Felker dal...@aerifal.cx wrote:
On Thu, Aug 01, 2013 at 01:29:51AM -0700, Christoph Hellwig wrote:
Btw, FreeBSD has an extension to shm_open to create unnamed but fd
passable segments. From their man page:
As a FreeBSD extension, the constant SHM_ANON
101 - 200 of 949 matches
Mail list logo
