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->
M_RESERVED)
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 p
(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 VM_BUG_O
flag 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
regres
> 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 = huge_
> 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 = huge_
>>> 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
(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
(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/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 ent
> @@ -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 = migrate_
>> -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)
>
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!
>
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
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..74
> 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_handle
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 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
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 "unsu
Hi Lee-san
> Rik is currently out on holiday and I've been traveling. Just getting
> back to rebasing to 24-rc8-mm1. Thank you for your efforts in testing
> and tracking down the regressions. I will add your fixes into my tree
> and try them out and let you know. Rik mentioned to me that he ha
> I will integrate your fixes with my code when I
> get back from holidays. Then things should work :)
>
> Thank you for your analysis of the problem.
Thank you.
enjoy good vacation :)
-
kosaki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
Hi
I tested numactl on 2.6.24-rc8-mm1.
and I found strange behavior.
test method and result.
$ numactl --interleave=all ls
set_mempolicy: Invalid argument
setting interleave mask: Invalid argument
numactl command download from
ftp://ftp.suse.com/pub/people/ak/num
land process should check has_high_memory file.
but, I am not confident.
Thanks.
- kosaki
Signed-off-by: KOSAKI Motohiro <[EMAIL PROTECTED]>
---
drivers/base/node.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
Index: b/drivers/base/node.c
==
Hi Jon
> I looked at this a year or two back, then ran out of time. But the thing
> I wanted to do was have libc's memory allocation routines extended to
> handle these through reservations - the kernel should send a userspace
> notification and then there should be some kind of concept of returni
Hi Pavel
> > > As user pages are always in highmem, this should be easy to decide:
> > > only send SIGDANGER when highmem is full. (Yes, there are
> > > inodes/dentries/file descriptors in lowmem, but I doubt apps will
> > > respond to SIGDANGER by closing files).
> >
> > Good point; for a system
on of
> interleaved pages over the nodes that do have memory. This is one of
> the memoryless nodes fixes. I THINK this is one of the areas that Paul
> and David are investigating.
this is good news for me :)
I'll wait his patch post.
Signed-off-by: KOSAKI Motohiro <[EMAIL PROT
Hi Paul
> Hopefully this week or next, I will publish this patch proposal.
Great.
at that time, I will join review the patch with presure :)
- kosaki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
On Mon, Oct 1, 2012 at 8:34 PM, Ni zhan Chen wrote:
> On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote:
>>
>> From: Wen Congyang
>>
>> The function acpi_bus_remove() can remove a acpi device from acpi device.
>
> IIUC, s/acpi device/acpi bus
IIUC, acpi_bus_remove() mean "remove the device from
>> Then, you introduced bisect breakage. It is definitely unacceptable.
>
> What is "bisect breakage" meaning?
Think what's happen when only applying path [1/21].
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More m
v = p;
>
> - seq_printf(m, "0x%p-0x%p %7ld",
> + seq_printf(m, "0x%pK-0x%pK %7ld",
> v->addr, v->addr + v->size, v->size);
Looks good.
Acked-by: KOSAKI Motohiro
--
To unsubscribe from this list: send the line "unsubscribe
CC: Jiang Liu
> CC: Len Brown
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> Signed-off-by: Yasuaki Ishimatsu
> Signed-off-by: Wen Congyang
> ---
> drivers/acpi/acpi_memhotplug.c | 44
> +++
y() to offline_memory(). We will
> use rename_memory() for hot removing memory.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> Signed-off-by: Yasuaki Ishimatsu
&
> I have the reason to have to fill the node struct with 0 by memset.
> The node is a part of node struct array (node_devices[]).
> If we add empty release function for suppressing warning,
> some data remains in the node struct after hot removing memory.
> So if we re-hot adds the memory, the node
On Wed, Oct 3, 2012 at 6:09 AM, Yasuaki Ishimatsu
wrote:
> From: Yasuaki Ishimatsu
>
> For hot removing physical memory, the patch adds remove_memory() into
> acpi_memory_remove_memory(). But we cannot support physical memory
> hot remove. So remove_memory() do nothinig.
I don't understand this
On Wed, Oct 3, 2012 at 6:11 AM, Yasuaki Ishimatsu
wrote:
> From: Wen Congyang
>
> The memory device has only one node id. Store the node id when
> enable the memory device, and we can reuse it when removing the
> memory device.
You don't explain why we need this. Then nobody can review nor ack.
> Known problems:
> 1. memory can't be offlined when CONFIG_MEMCG is selected.
>For example: there is a memory device on node 1. The address range
>is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
>and memory11 under the directory /sys/devices/system/memory/.
>
the check.
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> Signed-off-by: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/base/memory.c |
; CC: Jiang Liu
> CC: Len Brown
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> Signed-off-by: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
>
> ---
> drivers/firmware/memmap.c| 98
> ++
>> 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 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 ac
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 additional
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
> > the Linux Today article is very nice description. (great works by Jake Edge)
> > http://www.linuxworld.com/news/2008/020508-kernel.html
>
> Just for future reference...the above-mentioned article is from LWN,
> syndicated onto LinuxWorld. It has, so far as I know, never been near
> Linux Today
, remove
the in-line nodes_and() from sys_mbind(). I believe that this
restores mbind() to the behavior before the memoryless-nodes
patch series. E.g., we'll no longer treat an invalid nodemask
with MPOL_PREFERRED as local allocation.
Signed-off-by: Lee Schermerhorn <[EM
Hi David,
In general, I like this feature.
and I found no bug in patch [1/4] and [2/4].
> @@ -218,21 +167,27 @@ static struct mempolicy *mpol_new(enum mempolicy_mode
> mode,
> return ERR_PTR(-ENOMEM);
> flags &= MPOL_MODE_FLAGS;
> atomic_set(&policy->refcnt, 1);
>
Hi Andrew
> > and, It is judged out of trouble at the fllowing situations.
> > o memory pressure decrease and stop moves an anonymous page to the
> > inactive list.
> > o free pages increase than (pages_high+lowmem_reserve)*2.
>
> This seems rather arbitrary. Why choose this stage in the page
Hi
> > please ack.
>
> As it's now post -rc1 and not a 100% obvious thing, I tend to hang onto
> such patches for a week or so before sending up to Linus
Thanks, really thanks.
> Should this be backported to 2.6.24.x? If so, the reasons for such a
> relatively stern step should be spelled out
Hi Greg
> In the big "linux-next" series of emails, David Miller suggested that
> the feature-removal-schedule file be broken up into little pieces, as it
> is causing merge problems for different trees.
>
> This changeset does just that. Turns out that this makes things more
> readable, as it's
Hi Andi,
> > to be honest, I don't think at mem-cgroup until now.
>
> There is not only mem-cgroup BTW, but also NUMA node restrictons from
> NUMA memory policy. So this means a process might not be able to access
> all memory.
you are right.
good point out.
current implementation may cause wak
Hi Paul,
> The following adds one more bitmap operator, with the usual
> cpumask and nodemask wrappers. This operator computes one
> bitmap relative to another. If the n-th bit in the origin
> mask is set, then the m-th bit of the destination mask will
> be set, where m is the position of t
Hi Ray,
> > > i prefer another name [!relative].
> >
> > Any suggestions?
> >
> > I'll give the name some thought myself.
> > I like good names, and this is the right
> > time to get this one right.
>
> 'Relative map' implies a constant offset. What you have there is just
> a map as relmap c
Hi Paul,
> The bitmap_fold() operator folds a bitmap into a second that
> has bit m set iff the input bitmap has some bit n set, where
> m == n mod sz, for the specified sz value.
iff?
other portions looks good :)
Reviewed-by: KOSAKI Motohiro <[EMAIL PROTECTED]>
Thanks!
--
To u
>> > 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.
>
>
>> - 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 alr
On Tue, Sep 25, 2012 at 9:56 AM, Naoya Horiguchi
wrote:
> KPF_THP can be set on non-huge compound pages like slab pages, because
> PageTransCompound only sees PG_head and PG_tail. Obviously this is a bug
> and breaks user space applications which look for thp via /proc/kpageflags.
> Currently thp
On Tue, Sep 25, 2012 at 1:05 PM, Naoya Horiguchi
wrote:
> On Tue, Sep 25, 2012 at 11:59:51AM -0400, KOSAKI Motohiro wrote:
>> On Tue, Sep 25, 2012 at 9:56 AM, Naoya Horiguchi
>> wrote:
>> > KPF_THP can be set on non-huge compound pages like slab pages, because
>>
> +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_pag
(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 "unsubsc
(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 fi
(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
> --- a/mm/process_vm_access.c
(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
higher than the saved one.
A warning is printed when the new value is ignored.
Signed-off-by: Michal Hocko
Thank you. I have similar patch and I have been bothered long time to
refine and post it.
Yes, current logic is not memory hotplug aware and could be dangerous.
Acked-by: KOSAKI Motohiro
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
>
(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 Mot
epresents vmap_area is being tear
> 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: Joonso
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:
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
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 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
>>>
>>>
(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 core
x27;r' : '-',
- flags & VM_WRITE ? 'w' : '-',
- flags & VM_EXEC ? 'x' : '-',
- flags & VM_MAYSHARE ? flags & VM_SHARED ? 'S' : 's' : 'p',
- pgoff,
-
(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
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 mig
(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
w
t;Test Pass: Error at mmap: %s\n", strerror(errno));
> return 0;
> }
>
> if (pa == MAP_FAILED)
> perror("Test FAIL: expect EOVERFLOW but get other error");
> else
> printf("Test FAIL : Expect EOVERFLOW bu
not keen on this approach because it partially duplicates sp_alloc(). As
> the paths were sp->lock is taken are not that performance critical this
> patch converts sp->lock to sp->mutex so it can sleep when calling sp_alloc().
Looks make sense.
Acked-by: KOSAKI Motohiro
--
To unsubscr
race occurs, alloc_pages_vma() falls in 'goto
> retry_cpuset' path, decrements the reference count and frees the policy
> prematurely.
>
> Signed-off-by: KOSAKI Motohiro
> Signed-off-by: Mel Gorman
> ---
> mm/mempolicy.c | 12 +++-
> 1 files changed, 11
>> I've seen the exactly same patch from another fujitsu guys several
>> month ago. and as I pointed
>> out at that time, this line don't work when 32bit kernel + mmap2 syscall
>> case.
>>
>> Please don't think do_mmap_pgoff() is for mmap(2) specific and read a
>> past thread before resend
>> a pa
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: trinity-child2
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_release().
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
> 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 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, n
> + 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_ s
>> 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 5581c71e68a7f50e52fd67cca0014
to register_node(). 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 Mot
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 explanatio
[ 59.659720] 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
&
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. (curre
rwise we will 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
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 th
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.
>
>
> 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 t
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
> 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 section
. By this, task->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 o
1 - 100 of 478 matches
Mail list logo
