On Thu, Feb 28, 2013 at 6:54 PM, Andrew Morton
wrote:
> On Thu, 28 Feb 2013 00:25:07 -0500
> kosaki.motoh...@gmail.com wrote:
>
>> From: KOSAKI Motohiro
>>
>> Currently, n_new is wrongly initialized. start and end parameter
>> are inverted. Let's fix it.
>
On Thu, Feb 28, 2013 at 6:54 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Thu, 28 Feb 2013 00:25:07 -0500
kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently, n_new is wrongly initialized. start and end parameter
are inverted. Let's fix
On Thu, Feb 28, 2013 at 1:53 AM, Hillf Danton dhi...@gmail.com wrote:
On Thu, Feb 28, 2013 at 1:26 PM, KOSAKI Motohiro
kosaki.motoh...@jp.fujitsu.com wrote:
Insert new node after updating node in tree.
Thanks. you are right. I could reproduce and verified.
Thank you too;) pleasure to do
> -{
> - .procname = "hugepages_treat_as_movable",
> - .data = _treat_as_movable,
> - .maxlen = sizeof(int),
> - .mode = 0644,
> - .proc_handler = hugetlb_treat_movable_handler,
> -
> Insert new node after updating node in tree.
Thanks. you are right. I could reproduce and verified.
--
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
From: KOSAKI Motohiro
Currently, n_new is wrongly initialized. start and end parameter
are inverted. Let's fix it.
Signed-off-by: KOSAKI Motohiro
---
mm/mempolicy.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 868d08f..7431001
From: KOSAKI Motohiro
From: Hillf Danton
n->end is accessed in sp_insert(). Thus it should be update
before calling sp_insert(). This mistake may make kernel panic.
Signed-off-by: Hillf Danton
Signed-off-by: KOSAKI Motohiro
---
mm/mempolicy.c |2 +-
1 files changed, 1 insertions(+)
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
From: Hillf Danton dhi...@gmail.com
n-end is accessed in sp_insert(). Thus it should be update
before calling sp_insert(). This mistake may make kernel panic.
Signed-off-by: Hillf Danton dhi...@gmail.com
Signed-off-by: KOSAKI Motohiro
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently, n_new is wrongly initialized. start and end parameter
are inverted. Let's fix it.
Signed-off-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
---
mm/mempolicy.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
Insert new node after updating node in tree.
Thanks. you are right. I could reproduce and verified.
--
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
-{
- .procname = hugepages_treat_as_movable,
- .data = hugepages_treat_as_movable,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = hugetlb_treat_movable_handler,
-
On Mon, Feb 25, 2013 at 8:30 AM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running latest -next
> kernel,
> I've stumbled on the following BUG:
>
> [13551.830090] [ cut here ]
> [13551.830090] kernel BUG at mm/mempolicy.c:2187!
>
On Mon, Feb 25, 2013 at 8:30 AM, Sasha Levin sasha.le...@oracle.com wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel,
I've stumbled on the following BUG:
[13551.830090] [ cut here ]
[13551.830090] kernel BUG at
s
> definitions).
>
> But the Makefile, which turns kcmp.o generation on
> still depends on former config-x86. Thus get rid
> of this limitation and make kcmp.o depend on CONFIG_KCMP
> option.
Acked-by: KOSAKI Motohiro
--
To unsubscribe from this list: send the line "
definitions).
But the Makefile, which turns kcmp.o generation on
still depends on former config-x86. Thus get rid
of this limitation and make kcmp.o depend on CONFIG_KCMP
option.
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
To unsubscribe from this list: send the line unsubscribe
> Good question.
>
> There are 19 free bits in my configuration but it's related to
> CONFIG_NODES_SHIFT which is 9 for me (512 nodes) and very heavily affected
> by options such as CONFIG_SPARSEMEM_VMEMMAP. Memory hot-remove does not work
> with CONFIG_SPARSEMEM_VMEMMAP and enterprise
Good question.
There are 19 free bits in my configuration but it's related to
CONFIG_NODES_SHIFT which is 9 for me (512 nodes) and very heavily affected
by options such as CONFIG_SPARSEMEM_VMEMMAP. Memory hot-remove does not work
with CONFIG_SPARSEMEM_VMEMMAP and enterprise distribution
On 1/17/2013 11:30 AM, Luck, Tony wrote:
>> 2. If the user *does* care which nodes are movable, then the user needs
>> to be able to specify that *in a way that makes sense to the user*.
>> This may mean involving the DMI information as well as SRAT in order to
>> get "silk screen" type
On 1/16/2013 6:00 PM, H. Peter Anvin wrote:
> On 01/16/2013 02:01 PM, KOSAKI Motohiro wrote:
>>>>>
>>>>> Things I'm wondering:
>>>>>
>>>>> - is there *really* a case for retaining the boot option if/when
>>>>>SRAT
On 1/16/2013 8:49 PM, Tang Chen wrote:
> On 01/17/2013 06:52 AM, H. Peter Anvin wrote:
>> On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur
On 1/16/2013 8:49 PM, Tang Chen wrote:
On 01/17/2013 06:52 AM, H. Peter Anvin wrote:
On 01/16/2013 01:29 PM, Andrew Morton wrote:
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit are managed by ZONEMOVABLE. But performance degradation may
occur by NUMA because we
On 1/16/2013 6:00 PM, H. Peter Anvin wrote:
On 01/16/2013 02:01 PM, KOSAKI Motohiro wrote:
Things I'm wondering:
- is there *really* a case for retaining the boot option if/when
SRAT support is available?
Yes. If SRAT support is available, all memory which enabled hotpluggable
bit
On 1/17/2013 11:30 AM, Luck, Tony wrote:
2. If the user *does* care which nodes are movable, then the user needs
to be able to specify that *in a way that makes sense to the user*.
This may mean involving the DMI information as well as SRAT in order to
get silk screen type information out.
On 1/16/2013 4:29 PM, Andrew Morton wrote:
> On Wed, 16 Jan 2013 15:25:44 +0900
> Yasuaki Ishimatsu wrote:
>
>>>
>>> Things I'm wondering:
>>>
>>> - is there *really* a case for retaining the boot option if/when
>>>SRAT support is available?
>>
>> Yes. If SRAT support is available, all
On 1/16/2013 4:29 PM, Andrew Morton wrote:
On Wed, 16 Jan 2013 15:25:44 +0900
Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com wrote:
Things I'm wondering:
- is there *really* a case for retaining the boot option if/when
SRAT support is available?
Yes. If SRAT support is available,
; else
> node_set(pol->v.preferred_node, nodes);
> break;
> @@ -2796,10 +2787,7 @@ int mpol_to_str(char *buffer, int maxlen
> case MPOL_BIND:
> /* Fall through */
> case MPOL_INTERLEAVE:
> -
On Wed, Jan 2, 2013 at 5:04 AM, Hugh Dickins wrote:
> Remove the unused argument (formerly no_context) from mpol_parse_str()
> and from mpol_to_str().
>
> Signed-off-by: Hugh Dickins
Acked-by: KOSAKI Motohiro
--
To unsubscribe from this list: send the line "unsubsc
he
> problem in practice anyway.
Sorry for the long time silince. I broke my stomach and I didn't actively
developed last year. I apologize this.
Anyway, I ran basic tests of mempolicy again and I have no seen any
failure. Thus
Signed-off-by: KOSAKI Motohiro
Tested-by: KOSAKI Motohi
in practice anyway.
Sorry for the long time silince. I broke my stomach and I didn't actively
developed last year. I apologize this.
Anyway, I ran basic tests of mempolicy again and I have no seen any
failure. Thus
Signed-off-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Tested-by: KOSAKI Motohiro
On Wed, Jan 2, 2013 at 5:04 AM, Hugh Dickins hu...@google.com wrote:
Remove the unused argument (formerly no_context) from mpol_parse_str()
and from mpol_to_str().
Signed-off-by: Hugh Dickins hu...@google.com
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
--
To unsubscribe from
and after hot plugging.
Anyway, I have no seen any problems.
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
(12/12/12 11:49 PM), Dave Hansen wrote:
> On 12/12/2012 06:03 PM, Davidlohr Bueso wrote:
>> On Wed, 2012-12-12 at 17:48 -0800, Dave Hansen wrote:
>>> But if we went and did it per-DIMM (showing which physical addresses and
>>> NUMA nodes a DIMM maps to), wouldn't that be redundant with this
>>>
(12/12/12 11:49 PM), Dave Hansen wrote:
On 12/12/2012 06:03 PM, Davidlohr Bueso wrote:
On Wed, 2012-12-12 at 17:48 -0800, Dave Hansen wrote:
But if we went and did it per-DIMM (showing which physical addresses and
NUMA nodes a DIMM maps to), wouldn't that be redundant with this
proposed
>> - making zero page daemon and avoid pagesize zero fill at page fault
>> - making new vma or page flags and mark as discardable w/o swap and
>> vmscan treat it. (like this and/or MADV_FREE)
>
> Thanks for the information.
> I realized by you I'm not first people to think of this idea.
> Rik
>> > Allocator should call madvise(MADV_NOVOLATILE) before reusing for
>> > allocating that area to user. Otherwise, accessing of volatile range
>> > will meet SIGBUS error.
>>
>> Well, why? It would be easy enough for the fault handler to give
>> userspace a new, zeroed page at that address.
>
>
Allocator should call madvise(MADV_NOVOLATILE) before reusing for
allocating that area to user. Otherwise, accessing of volatile range
will meet SIGBUS error.
Well, why? It would be easy enough for the fault handler to give
userspace a new, zeroed page at that address.
Note:
- making zero page daemon and avoid pagesize zero fill at page fault
- making new vma or page flags and mark as discardable w/o swap and
vmscan treat it. (like this and/or MADV_FREE)
Thanks for the information.
I realized by you I'm not first people to think of this idea.
Rik already
On Wed, Oct 24, 2012 at 5:43 AM, Lai Jiangshan wrote:
> Currently memory_hotplug only manages the node_states[N_HIGH_MEMORY],
> it forgets to manage node_states[N_NORMAL_MEMORY]. it may cause
> node_states[N_NORMAL_MEMORY] becomes incorrect.
>
> Example, if a node is empty before online, and we
On Wed, Oct 24, 2012 at 6:57 PM, Dave Hansen wrote:
> On 10/24/2012 03:48 PM, Borislav Petkov wrote:
>> On Wed, Oct 24, 2012 at 02:18:38PM -0700, Dave Hansen wrote:
>>> Sounds fairly valid to me. But, it's also one that would not be harmed
>>> or disrupted in any way because of a single
On Wed, Oct 24, 2012 at 8:08 PM, David Rientjes wrote:
> On Wed, 24 Oct 2012, Sasha Levin wrote:
>
>> > This should be fixed by 9e7814404b77 ("hold task->mempolicy while
>> > numa_maps scans.") in 3.7-rc2, can you reproduce any issues reading
>> > /proc/pid/numa_maps on that kernel?
>>
>> I was
>> I have drop_caches in my suspend-to-disk script so that the hibernation
>> image is kept at minimum and suspend times are as small as possible.
>
> hm, that sounds smart.
>
>> Would that be a valid use-case?
>
> I'd say so, unless we change the kernel to do that internally. We do
> have the
I have drop_caches in my suspend-to-disk script so that the hibernation
image is kept at minimum and suspend times are as small as possible.
hm, that sounds smart.
Would that be a valid use-case?
I'd say so, unless we change the kernel to do that internally. We do
have the
On Wed, Oct 24, 2012 at 8:08 PM, David Rientjes rient...@google.com wrote:
On Wed, 24 Oct 2012, Sasha Levin wrote:
This should be fixed by 9e7814404b77 (hold task-mempolicy while
numa_maps scans.) in 3.7-rc2, can you reproduce any issues reading
/proc/pid/numa_maps on that kernel?
I was
On Wed, Oct 24, 2012 at 6:57 PM, Dave Hansen d...@linux.vnet.ibm.com wrote:
On 10/24/2012 03:48 PM, Borislav Petkov wrote:
On Wed, Oct 24, 2012 at 02:18:38PM -0700, Dave Hansen wrote:
Sounds fairly valid to me. But, it's also one that would not be harmed
or disrupted in any way because of a
On Wed, Oct 24, 2012 at 5:43 AM, Lai Jiangshan la...@cn.fujitsu.com wrote:
Currently memory_hotplug only manages the node_states[N_HIGH_MEMORY],
it forgets to manage node_states[N_NORMAL_MEMORY]. it may cause
node_states[N_NORMAL_MEMORY] becomes incorrect.
Example, if a node is empty before
On Mon, Oct 22, 2012 at 11:11 AM, KOSAKI Motohiro
wrote:
>>> ??
>>> If resource was not allocated a driver, a driver doesn't need to
>>> deallocate it when
>>> error path. I haven't caught your point.
>>>
>>
>> REMOVAL_NORMAL can be in 2 c
>> ??
>> If resource was not allocated a driver, a driver doesn't need to
>> deallocate it when
>> error path. I haven't caught your point.
>>
>
> REMOVAL_NORMAL can be in 2 cases:
> 1. error path. If init call fails, we don't call it. We call this function
>only when something fails after
??
If resource was not allocated a driver, a driver doesn't need to
deallocate it when
error path. I haven't caught your point.
REMOVAL_NORMAL can be in 2 cases:
1. error path. If init call fails, we don't call it. We call this function
only when something fails after init.
2. unbind
On Mon, Oct 22, 2012 at 11:11 AM, KOSAKI Motohiro
kosaki.motoh...@jp.fujitsu.com wrote:
??
If resource was not allocated a driver, a driver doesn't need to
deallocate it when
error path. I haven't caught your point.
REMOVAL_NORMAL can be in 2 cases:
1. error path. If init call fails, we
On Fri, Oct 19, 2012 at 8:52 PM, Wen Congyang wrote:
> At 10/20/2012 02:11 AM, KOSAKI Motohiro Wrote:
>> On Fri, Oct 19, 2012 at 6:16 AM, wrote:
>>> From: Wen Congyang
>>>
>>> Current mem= implementation seems buggy because specification and
>>> i
device.res_list at the same time. This patch
> introduce a lock to protect this list.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Yasuaki Ishimatsu
> Signed-o
k->mempolicy
> will not be freed until numa_maps reaches its end.
>
> Signed-off-by: KAMEZAWA Hiroyuki
>
> V2->v3
> - updated comments to be more verbose.
> - removed task_lock() in numa_maps code.
> V1->V2
> - access task->mempolicy only once and rememb
> I think it again, and found that this check is necessary. Because we only
> lock memory hotplug when offlining pages. Here is the steps to offline and
> remove memory:
>
> 1. lock memory hotplug
> 2. offline a memory section
> 3. unlock memory hotplug
> 4. repeat 1-3 to offline all memory
n Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Yasuaki Ishimatsu
> Signed-off-by: Wen Congyang
> ---
> drivers/acpi/acpi_memhotplug.c |3 ++-
> 1 files changed, 2 insertions(+), 1 del
> Hmm, IIRC, if the memory is recognized from kerenl before driver
> initialization,
> the memory device is not managed by the driver acpi_memhotplug.
Yup.
> I think we should also deal with REMOVAL_NORMAL here now. Otherwise it will
> cause
> some critical problem: we unbind the device from
On Fri, Oct 19, 2012 at 6:16 AM, wrote:
> From: Wen Congyang
>
> Current mem= implementation seems buggy because specification and
> implementation doesn't match. Current mem= has been working
> for many years and it's not buggy, it works as expected. So
> we should update the specification.
>
On Fri, Oct 19, 2012 at 2:46 AM, wrote:
> From: Wen Congyang
>
> NR_FREE_PAGES will be wrong after offlining pages. We add/dec NR_FREE_PAGES
> like this now:
> 1. mova all pages in buddy system to MIGRATE_ISOLATE, and dec NR_FREE_PAGES
move?
> 2. don't add NR_FREE_PAGES when it is freed and
ill lose
> some free pages.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Yasuaki Ishimatsu
> Signe
On Fri, Oct 19, 2012 at 2:46 AM, wrote:
> From: Wen Congyang
>
> When we hotremove a memory device, we will free the memory to store
> struct page. If the page is hwpoisoned page, we should decrease
> mce_bad_pages.
I think [5/9] and [6/9] should be fold. Their two patches fix one
issue.
720] Disabling lock debugging due to kernel taint
>
> This patch clears the memory to store struct page to avoid unexpected error.
>
> CC: David Rientjes
> CC: Jiang Liu
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Yasuaki Ishimatsu
> Report
On Fri, Oct 19, 2012 at 2:46 AM, wrote:
> From: Yasuaki Ishimatsu
>
> If the node is onlined after it is offlined, we will clear the memory
> to store the node's information. This structure contains struct work,
> so we should flush work before the work's information is cleared.
This
Because the node
> struct is part of node_devices[] array and it cannot be freed by
> node_device_release(). So if system reuses the node struct, it has a garbage.
>
> CC: David Rientjes
> CC: Jiang Liu
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> Signed-o
>> Can't we have another way to fix ? like this ? too ugly ?
>> Again, I'm sorry if I misunderstand the points.
>>
> Sorry this patch itself may be buggy. please don't test..
> I missed that kernel/exit.c sets task->mempolicy to be NULL.
> fixed one here.
>
> --
> From
Can't we have another way to fix ? like this ? too ugly ?
Again, I'm sorry if I misunderstand the points.
Sorry this patch itself may be buggy. please don't test..
I missed that kernel/exit.c sets task-mempolicy to be NULL.
fixed one here.
--
From 5581c71e68a7f50e52fd67cca00148911023f9f5
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
I still think node array should be converted node pointer array and
node_device_release() free memory as other typical drivers
On Fri, Oct 19, 2012 at 2:46 AM, we...@cn.fujitsu.com wrote:
From: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
If the node is onlined after it is offlined, we will clear the memory
to store the node's information. This structure contains struct work,
so we should flush work before the
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Reported-by: Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com
Signed-off-by: Wen Congyang we
On Fri, Oct 19, 2012 at 2:46 AM, we...@cn.fujitsu.com wrote:
From: Wen Congyang we...@cn.fujitsu.com
When we hotremove a memory device, we will free the memory to store
struct page. If the page is hwpoisoned page, we should decrease
mce_bad_pages.
I think [5/9] and [6/9] should be fold.
minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
Looks good.
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
On Fri, Oct 19, 2012 at 2:46 AM, we...@cn.fujitsu.com wrote:
From: Wen Congyang we...@cn.fujitsu.com
NR_FREE_PAGES will be wrong after offlining pages. We add/dec NR_FREE_PAGES
like this now:
1. mova all pages in buddy system to MIGRATE_ISOLATE, and dec NR_FREE_PAGES
move?
2. don't add
On Fri, Oct 19, 2012 at 6:16 AM, we...@cn.fujitsu.com wrote:
From: Wen Congyang we...@cn.fujitsu.com
Current mem= implementation seems buggy because specification and
implementation doesn't match. Current mem= has been working
for many years and it's not buggy, it works as expected. So
we
Hmm, IIRC, if the memory is recognized from kerenl before driver
initialization,
the memory device is not managed by the driver acpi_memhotplug.
Yup.
I think we should also deal with REMOVAL_NORMAL here now. Otherwise it will
cause
some critical problem: we unbind the device from the
...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh
I think it again, and found that this check is necessary. Because we only
lock memory hotplug when offlining pages. Here is the steps to offline and
remove memory:
1. lock memory hotplug
2. offline a memory section
3. unlock memory hotplug
4. repeat 1-3 to offline all memory sections
5.
/exit.c
can overwrite it.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.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
a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
drivers/acpi/acpi_memhotplug.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff
On Fri, Oct 19, 2012 at 8:52 PM, Wen Congyang we...@cn.fujitsu.com wrote:
At 10/20/2012 02:11 AM, KOSAKI Motohiro Wrote:
On Fri, Oct 19, 2012 at 6:16 AM, we...@cn.fujitsu.com wrote:
From: Wen Congyang we...@cn.fujitsu.com
Current mem= implementation seems buggy because specification
> + if (type == ACPI_BUS_REMOVAL_EJECT) {
> + /*
> +* offline and remove memory only when the memory device
> is
> +* ejected.
> +*/
This comment explain nothing. A comment should describe _why_
+ if (type == ACPI_BUS_REMOVAL_EJECT) {
+ /*
+* offline and remove memory only when the memory device
is
+* ejected.
+*/
This comment explain nothing. A comment should describe _why_ should we do.
e.g. Why REMOVAL_NORMAL
On Wed, Oct 17, 2012 at 3:50 PM, David Rientjes wrote:
> On Wed, 17 Oct 2012, KOSAKI Motohiro wrote:
>
>> > I think this refcounting is better than using task_lock().
>>
>> I don't think so. get_vma_policy() is used from fast path. In other
>> words, nu
> Hmm, it doesn't move the code. It just reuse the code in
> acpi_memory_powerdown_device().
Even if reuse or not reuse, you changed the behavior. If any changes
has no good rational, you cannot get an ack.
>>>
>>> I don't understand this? IIRC, the behavior isn't changed.
On Wed, Oct 17, 2012 at 2:48 AM, Wen Congyang wrote:
> At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
>>>>> -static int acpi_memory_disable_device(struct acpi_memory_device
>>>>> *mem_device)
>>>>> +static int acpi_memory_remove_mem
On Wed, Oct 17, 2012 at 2:24 AM, Wen Congyang wrote:
> At 10/12/2012 06:33 AM, KOSAKI Motohiro Wrote:
>> On Thu, Oct 11, 2012 at 1:26 AM, Yasuaki Ishimatsu
>> wrote:
>>> When calling unregister_node(), the function shows following message at
>>> device_releas
On Wed, Oct 17, 2012 at 1:42 AM, Kamezawa Hiroyuki
wrote:
> (2012/10/17 14:24), David Rientjes wrote:
>>
>> On Wed, 17 Oct 2012, Dave Jones wrote:
>>
>>> BUG: sleeping function called from invalid context at kernel/mutex.c:269
>>> in_atomic(): 1, irqs_disabled(): 0, pid: 8558, name:
On Wed, Oct 17, 2012 at 1:42 AM, Kamezawa Hiroyuki
kamezawa.hir...@jp.fujitsu.com wrote:
(2012/10/17 14:24), David Rientjes wrote:
On Wed, 17 Oct 2012, Dave Jones wrote:
BUG: sleeping function called from invalid context at kernel/mutex.c:269
in_atomic(): 1, irqs_disabled(): 0, pid: 8558,
On Wed, Oct 17, 2012 at 2:24 AM, Wen Congyang we...@cn.fujitsu.com wrote:
At 10/12/2012 06:33 AM, KOSAKI Motohiro Wrote:
On Thu, Oct 11, 2012 at 1:26 AM, Yasuaki Ishimatsu
isimatu.yasu...@jp.fujitsu.com wrote:
When calling unregister_node(), the function shows following message
On Wed, Oct 17, 2012 at 2:48 AM, Wen Congyang we...@cn.fujitsu.com wrote:
At 10/13/2012 03:10 AM, KOSAKI Motohiro Wrote:
-static int acpi_memory_disable_device(struct acpi_memory_device
*mem_device)
+static int acpi_memory_remove_memory(struct acpi_memory_device
*mem_device
Hmm, it doesn't move the code. It just reuse the code in
acpi_memory_powerdown_device().
Even if reuse or not reuse, you changed the behavior. If any changes
has no good rational, you cannot get an ack.
I don't understand this? IIRC, the behavior isn't changed.
Heh, please explain why do
On Wed, Oct 17, 2012 at 3:50 PM, David Rientjes rient...@google.com wrote:
On Wed, 17 Oct 2012, KOSAKI Motohiro wrote:
I think this refcounting is better than using task_lock().
I don't think so. get_vma_policy() is used from fast path. In other
words, number of
atomic ops is sensible
On Tue, Oct 16, 2012 at 9:49 PM, David Rientjes wrote:
> On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
>
>> > diff --git a/mm/mempolicy.c b/mm/mempolicy.c
>> > index 0b78fb9..d04a8a5 100644
>> > --- a/mm/mempolicy.c
>> > +++ b/mm/mempolicy.c
On Tue, Oct 16, 2012 at 8:31 PM, David Rientjes wrote:
> When reading /proc/pid/numa_maps, it's possible to return the contents of
> the stack where the mempolicy string should be printed if the policy gets
> freed from beneath us.
>
> This happens because mpol_to_str() may return an error the
>
On Tue, Oct 16, 2012 at 8:12 PM, David Rientjes wrote:
> On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
>
>> >> Even though 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a itself is simple. It
>> >> bring
>> >> to caller complex. That's not good and have no worth.
On Tue, Oct 16, 2012 at 2:10 AM, David Rientjes wrote:
> On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
>
>> >> I don't think 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a is right fix.
>> >
>> > It's certainly not a complete fix, but I think it's a much better re
On Tue, Oct 16, 2012 at 2:10 AM, David Rientjes rient...@google.com wrote:
On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
I don't think 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a is right fix.
It's certainly not a complete fix, but I think it's a much better result
of the race, i.e. we don't
On Tue, Oct 16, 2012 at 8:12 PM, David Rientjes rient...@google.com wrote:
On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
Even though 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a itself is simple. It
bring
to caller complex. That's not good and have no worth.
Before: the kernel panics, all
On Tue, Oct 16, 2012 at 8:31 PM, David Rientjes rient...@google.com wrote:
When reading /proc/pid/numa_maps, it's possible to return the contents of
the stack where the mempolicy string should be printed if the policy gets
freed from beneath us.
This happens because mpol_to_str() may return
On Tue, Oct 16, 2012 at 9:49 PM, David Rientjes rient...@google.com wrote:
On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 0b78fb9..d04a8a5 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1536,9 +1536,8 @@ asmlinkage long
On Mon, Oct 15, 2012 at 11:58 PM, David Rientjes wrote:
> On Mon, 15 Oct 2012, KOSAKI Motohiro wrote:
>
>> I don't think 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a is right fix.
>
> It's certainly not a complete fix, but I think it's a much better result
> of the race, i.e. w
ut affecting a hierarchy of groups only.
> +Please note that unlike the global swappiness, memcg knob set to 0
> +really prevents from any swapping even if there is a swap storage
> +available. This might lead to memcg OOM killer if there are no file
> +pages to reclaim.
Pretty good
> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
> index 078701f..308fd77 100644
> --- a/Documentation/sysctl/vm.txt
> +++ b/Documentation/sysctl/vm.txt
> @@ -640,6 +640,9 @@ swappiness
> This control is used to define how aggressive the kernel will swap
> memory pages.
501 - 600 of 949 matches
Mail list logo
