(2013/01/10 17:36), Glauber Costa wrote:
BTW, shrink_slab() is now node/zone aware ? If not, fixing that first will
be better direction I guess.
It is not upstream, but there are patches for this that I am already
using in my private tree.
Oh, I see. If it's merged, it's worth add "shrink_
(2013/01/10 16:55), Glauber Costa wrote:
On 01/10/2013 11:31 AM, Kamezawa Hiroyuki wrote:
(2013/01/10 16:14), Glauber Costa wrote:
On 01/10/2013 06:17 AM, Tang Chen wrote:
Note: if the memory provided by the memory device is used by the
kernel, it
can't be offlined. It is not a bug.
(2013/01/10 16:14), Glauber Costa wrote:
On 01/10/2013 06:17 AM, Tang Chen wrote:
Note: if the memory provided by the memory device is used by the
kernel, it
can't be offlined. It is not a bug.
Right. But how often does this happen in testing? In other words,
please provide an overall descri
(2012/12/30 15:02), Wen Congyang wrote:
> At 12/28/2012 08:28 AM, Kamezawa Hiroyuki Wrote:
>> (2012/12/27 21:16), Wen Congyang wrote:
>>> At 12/26/2012 11:55 AM, Kamezawa Hiroyuki Wrote:
>>>> (2012/12/24 21:09), Tang Chen wrote:
>>>>> From: Wen Congya
(2012/12/27 21:16), Wen Congyang wrote:
> At 12/26/2012 11:55 AM, Kamezawa Hiroyuki Wrote:
>> (2012/12/24 21:09), Tang Chen wrote:
>>> From: Wen Congyang
>>>
>>> We call hotadd_new_pgdat() to allocate memory to store node_data. So we
>>> should free i
(2012/12/24 21:09), Tang Chen wrote:
> From: Wen Congyang
>
> We call hotadd_new_pgdat() to allocate memory to store node_data. So we
> should free it when removing a node.
>
> Signed-off-by: Wen Congyang
I'm sorry but is it safe to remove pgdat ? All zone cache and zonelists are
properly clea
FIX or -fix- in patch title
will be appreciated, I think.
Acked-by: KAMEZAWA Hiroyuki
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
(2012/12/24 21:09), Tang Chen wrote:
> From: Wen Congyang
>
> 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 director
move_pages() for some archtecuture is not implemented
>(I don't know how to implement it for s390).
>
> Signed-off-by: Wen Congyang
Then, remove code will be symetric to add codes.
Acked-by: KAMEZAWA Hiroyuki
___
Lin
(2012/12/24 21:09), Tang Chen wrote:
> From: Yasuaki Ishimatsu
>
> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
> sysfs files are created. But there is no code to remove these files. The patch
> implements the function to remove them.
>
> Note: The code does not
(2012/12/24 21:09), Tang Chen wrote:
> From: Wen Congyang
>
> offlining memory blocks and checking whether memory blocks are offlined
> are very similar. This patch introduces a new function to remove
> redundant codes.
>
> Signed-off-by: Wen Congyang
> ---
> mm/memory_hotplug.c | 101
> +++
-by: Wen Congyang
> Signed-off-by: Yasuaki Ishimatsu
Acked-by: KAMEZAWA Hiroyuki
a nitpick below.
> ---
> drivers/base/memory.c |6 +
> include/linux/memory_hotplug.h |1 +
> mm/memory_hotplug.c| 47
> +
code up.
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Paul Mundt
Signed-off-by: David Rientjes
I think this is good.
Reviewed-by: KAMEZAWA Hiroyuki
___
Linuxppc-dev ma
to
> maybe something like the x86 version). It looks like the sparc version
> is broken as well.
>
Sorry, here is a fix I posted today. but no ack yet.
==
>From 507cc95c5ba2351bff16c5421255d1395a3b555b Mon Sep 17 00:00:00 2001
From: KAMEZAWA Hiroyuki
Date: Thu, 16 Jun 2011 1
On Tue, 26 Oct 2010 16:03:56 +0530
Subrata Modak wrote:
> If you run LTP Memory CGROUP Controller functional test on
> linux-2.6.36-git7, the following Backtrace, OOMKill & rcu_sched_state
> detected stall jiffies are created. The machine is not reachable
> thereafter. Ways to reproduce this prob
Nathan Fontenot
>
Reviewed-By: KAMEZAWA Hiroyuki
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Fri, 01 Oct 2010 13:28:39 -0500
Nathan Fontenot wrote:
> Move the find_memory_block() routine up to avoid needing a forward
> declaration in subsequent patches.
>
> Signed-off-by: Nathan Fontenot
>
Reviewd-by: KAMEZAWA Hiroyuki
_
On Fri, 01 Oct 2010 13:37:49 -0500
Nathan Fontenot wrote:
> Update the memory hotplug documentation to reflect the new behaviors of
> memory blocks reflected in sysfs.
>
> Signed-off-by: Nathan Fontenot
>
Reviewed-by: KAMEZAWA Hiroyuki
Thank you for yo
t; parameter to unregister_mem_sect_under_nodes so that we know which memory
> section of the memory block to unregister.
>
> Signed-off-by: Nathan Fontenot
Reviewed-by: KAMEZAWA Hiroyuki
___
Linuxppc-dev mailing list
Linuxppc-dev@l
th what is stored here, namely the first and last section number
> that the memory block spans.
>
> The names presented to userspace remain the same, phys_index for
> start_section_nr and end_phys_index for end_section_nr, to avoid breaking
> anything in userspace.
>
> Signed-off-
routine.
>
This should be commented in code before MEMORY_BLOCK_SIZE declaration.
> Signed-off-by: Nathan Fontenot
>
Reviewed-by: KAMEZAWA Hiroyuki
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
has been
> removed so we can remove the memory block.
>
> Signed-off-by: Nathan Fontenot
>
Reviewed-by: KAMEZAWA Hiroyuki
a nitpick,
> Index: linux-next/include/linux/memory.h
> ===
> --- linux-next.orig/include/l
On Tue, 03 Aug 2010 08:44:16 -0500
Nathan Fontenot wrote:
> Update the memory hotplug documentation to reflect the new behaviors of
> memory blocks reflected in sysfs.
>
> Signed-off-by: Nathan Fontenot
Acked-by: KAMEZAWA Hiroyuki
A request from me:
Could you clarify what happ
; section of the memory block to unregister.
>
> Signed-off-by: Nathan Fontenot
Acked-by: KAMEZAWA Hiroyuki
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, 03 Aug 2010 08:41:45 -0500
Nathan Fontenot wrote:
> Update the find_memory_block declaration to to take a struct mem_section *
> so that it matches the definition.
>
> Signed-off-by: Nathan Fontenot
Acked-by: KAMEZAWA Hiroyuki
Hmm...my mmotm-0727 has this definition
>
> Signed-off-by: Nathan Fontenot
Acked-by: KAMEZAWA Hiroyuki
(But maybe it's better to get ppc guy's Ack.)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
enot
Acked-by: KAMEZAWA Hiroyuki
But a nitpick (see below)
> ---
> drivers/base/memory.c |9 +
> 1 file changed, 9 insertions(+)
>
> Index: linux-2.6/drivers/base/memory.c
> ===
> --- linux-2.6.
has been
> removed so we can remove the memory block.
>
> Signed-off-by: Nathan Fontenot
Acked-by: KAMEZAWA Hiroyuki
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
7; in sysfs but the memory_block
> struct name is updated to indicate the start and end values.
> This also adds an 'end_phys_index' property to indicate the id of the
> last section in th memory block.
>
> Signed-off-by: Nathan Fontenot
Acked-by: KAMEZAWA Hiroyuki
nitp
On Tue, 03 Aug 2010 08:36:39 -0500
Nathan Fontenot wrote:
> Move the find_memory_block() routine up to avoid needing a forward
> declaration in subsequent patches.
>
> Signed-off-by: Nathan Fontenot
Acked-by: KAMEZAWA Hiroyuki
___
; section of the memory block to unregister.
>
> Signed-off-by: Nathan Fontenot
Acked-by: KAMEZAWA Hiroyuki
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Mon, 19 Jul 2010 22:56:16 -0500
Nathan Fontenot wrote:
> Update the find_memory_block declaration to to take a struct mem_section *
> so that it matches the definition.
>
> Signed-off-by: Nathan Fontenot
Reviewd-by: KAMEZ
On Mon, 19 Jul 2010 22:55:08 -0500
Nathan Fontenot wrote:
> Update the memory sysfs code that each sysfs memory directory is now
> considered a memory block that can contain multiple memory sections per
> memory block. The default size of each memory block is SECTION_SIZE_BITS
> to maintain the
On Mon, 19 Jul 2010 22:53:58 -0500
Nathan Fontenot wrote:
> Add a section count property to the memory_block struct to track the number
> of memory sections that have been added/removed from a emory block.
>
> Signed-off-by: Nathan Fontenot
> ---
> drivers/base/memory.c | 19 ---
On Mon, 19 Jul 2010 22:52:50 -0500
Nathan Fontenot wrote:
> Update the 'phys_index' properties of a memory block to include a
> 'start_phys_index' which is the same as the current 'phys_index' property.
> This also adds an 'end_phys_index' property to indicate the id of the
> last section in th m
On Mon, 19 Jul 2010 22:51:42 -0500
Nathan Fontenot wrote:
> Move the find_me mory_block() routine up to avoid needing a forward
> declaration in subsequent patches.
>
> Signed-off-by: Nathan Fontenot
Acked-by: KAMEZAWA Hiroyuki
> ---
> drivers/ba
On Thu, 15 Jul 2010 13:40:40 -0500
Nathan Fontenot wrote:
> Update the node sysfs directory routines that create
> links to the memory sysfs directories under each node.
> This update makes the node code aware that a memory sysfs
> directory can cover multiple memory sections.
>
> Signed-off-by:
On Thu, 15 Jul 2010 13:38:52 -0500
Nathan Fontenot wrote:
> Add a new 'end_phys_index' file to each memory sysfs directory to
> report the physical index of the last memory section
> covered by the sysfs directory.
>
> Signed-off-by: Nathan Fontenot
Does memory_block have to be contiguous betw
On Thu, 15 Jul 2010 13:37:51 -0500
Nathan Fontenot wrote:
> Split the memory_block struct into a memory_block
> struct to cover each sysfs directory and a new memory_block_section
> struct for each memory section covered by the sysfs directory.
> This change allows for creation of memory sysfs di
On Wed, 14 Jul 2010 12:25:03 +0900
KAMEZAWA Hiroyuki wrote:
> On Tue, 13 Jul 2010 22:18:03 -0500
> Nathan Fontenot wrote:
>
> > On 07/13/2010 07:35 PM, KAMEZAWA Hiroyuki wrote:
> > > On Tue, 13 Jul 2010 10:51:58 -0500
> > > Nathan Fontenot wrote:
> >
On Tue, 13 Jul 2010 22:18:03 -0500
Nathan Fontenot wrote:
> On 07/13/2010 07:35 PM, KAMEZAWA Hiroyuki wrote:
> > On Tue, 13 Jul 2010 10:51:58 -0500
> > Nathan Fontenot wrote:
> >
> >>>
> >>> And for what purpose this interface is ? Does this split m
On Tue, 13 Jul 2010 10:51:58 -0500
Nathan Fontenot wrote:
> >
> > And for what purpose this interface is ? Does this split memory block into
> > 2 pieces
> > of the same size ?? sounds __very__ strange interface to me.
>
> Yes, this splits the memory_block into two blocks of the same size. Th
On Mon, 12 Jul 2010 10:45:25 -0500
Nathan Fontenot wrote:
> This patch introduces the new 'split' file in each memory sysfs
> directory and the associated routines needed to handle splitting
> a directory.
>
> Signed-off-by; Nathan Fontenot
> ---
pleae check diff option...
> drivers/base/me
On Mon, 12 Jul 2010 10:44:10 -0500
Nathan Fontenot wrote:
> This patch moves the register/unregister_memory routines to
> avoid a forward declaration. It also moves the sysfs file
> creation and deletion for each directory into the register/
> unregister routines to avoid duplicating it with the
plz cc linux-mm in the next time...
And please incudes updates for Documentation/memory-hotplug.txt.
On Mon, 12 Jul 2010 10:42:06 -0500
Nathan Fontenot wrote:
> This patch splits the memory_block struct into a memory_block
> struct to cover each sysfs directory and a new memory_block_section
>
On Thu, 10 Jun 2010 22:00:57 +0200
Maciej Rutecki wrote:
> I created a Bugzilla entry at
> https://bugzilla.kernel.org/show_bug.cgi?id=16178
> for your bug report, please add your address to the CC list in there, thanks!
>
Hmm... It seems a panic in SLUB or SLAB.
Is .config available ?
-Kame
.
==
swap_cgroup uses 2bytes data and uses cmpxchg in a new operation.
2byte cmpxchg/xchg is not available on some archs. This patch replaces
cmpxchg/xchg with operations under lock.
Signed-off-by: KAMEZAWA Hiroyuki
---
mm/page_cgroup.c | 20
1 file changed, 16 ins
e node (the mask argument is either
> NODE_MASK_ALL or node_online_map) just use the first_online_node
> macro and remove the any_online_node macro since there are no users.
>
Reviewed-by: KAMEZAWA Hiroyuki
Thank you.
BTW, it's better to add diffstat to this kind of changes.
Reg
On Fri, 2 Oct 2009 13:44:58 -0500
Robert Jennings wrote:
> Memory balloon drivers can allocate a large amount of memory which
> is not movable but could be freed to accomodate memory hotplug remove.
>
> Prior to calling the memory hotplug notifier chain the memory in the
> pageblock is isolated.
On Tue, 19 Feb 2008 09:58:38 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
> > when I inserted printk here
> > ==
> > for (i = 0; i < nr; i++)
> > func(ioc, cics[i]);
> > printk("%d %lx\n", nr, index);
> > ==
> > index was always "1" and nr was always 32.
> >
> > So, cics[31]->k
On Tue, 19 Feb 2008 09:36:34 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> > On Sun, 17 Feb 2008 20:29:13 +0100
> > Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > > It's odd stuff. Could you perh
On Tue, 19 Feb 2008 09:36:34 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 19 2008, KAMEZAWA Hiroyuki wrote:
> > On Sun, 17 Feb 2008 20:29:13 +0100
> > Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > > It's odd stuff. Could you perh
ics[]->key can be NULL.
In that case, cics[]->dead_key has key value.
Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
Index: linux-2.6.25-rc2/block/cfq-iosched.c
===
--- linux-2.6.25-rc2.orig/block/cfq-iosc
On Wed, 31 Oct 2007 14:55:03 -0700
Dave Hansen <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-10-31 at 14:11 -0800, Badari Pulavarty wrote:
> >
> > Well, We don't need arch-specific remove_memory() for ia64 and ppc64.
> > x86_64, I don't know. We will know, only when some one does the
> > verification
On Wed, 31 Oct 2007 08:02:40 -0800
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Paul's concern is, since we didn't need it so far - why we need this
> for hotplug memory remove to work ? It might break API for *unknown*
> applications. Its unfortunate that, hotplug memory add updates
> /proc/iome
On Wed, 31 Oct 2007 14:28:46 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> ioresource was good structure for remembering "which memory is conventional
> memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> when I posted patch
On Tue, 30 Oct 2007 11:19:11 -0800
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi KAME,
>
> As I mentioned while ago, ppc64 does not export information about
> "system RAM" in /proc/iomem. Looking at the code and usage
> scenerios I am not sure what its really serving. Could you
> explain what
On Wed, 03 Oct 2007 08:35:35 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-10-03 at 10:19 +0900, KAMEZAWA Hiroyuki wrote:
> CONFIG_ARCH_HAS_VALID_MEMORY_RANGE. Then define own
> find_next_system_ram() (rename to is_valid_memory_range()) - which
> checks th
On Tue, 02 Oct 2007 16:10:53 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> > > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > > code to be able to do this.
> >
> > Isn't it just a matter of abstracting the test for a valid range of
> > memory? If it's really hard to abs
59 matches
Mail list logo
