All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: wency@cn.fujitsu.com
Cc: x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-ia64@vger.kernel.org, cmetcalf@tilera.com,
	sparclinux@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, benh@kernel.crashing.org,
	paulus@samba.org, cl@linux.com, minchan.kim@gmail.com,
	kosaki.motohiro@jp.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com
Subject: Re: [RFC v8 PATCH 08/20] memory-hotplug: remove /sys/firmware/memmap/X sysfs
Date: Fri, 31 Aug 2012 14:06:23 -0700	[thread overview]
Message-ID: <20120831140623.8d13bd2c.akpm@linux-foundation.org> (raw)
In-Reply-To: <1346148027-24468-9-git-send-email-wency@cn.fujitsu.com>

On Tue, 28 Aug 2012 18:00:15 +0800
wency@cn.fujitsu.com wrote:

> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> 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 free firmware_map_entry since there is no way to free
>        memory which is allocated by bootmem.
> 
> ....
>
> +#define to_memmap_entry(obj) container_of(obj, struct firmware_map_entry, kobj)

It would be better to implement this as an inlined C function.  That
has improved type safety and improved readability.

> +static void release_firmware_map_entry(struct kobject *kobj)
> +{
> +	struct firmware_map_entry *entry = to_memmap_entry(kobj);
> +	struct page *page;
> +
> +	page = virt_to_page(entry);
> +	if (PageSlab(page) || PageCompound(page))

That PageCompound() test looks rather odd.  Why is this done?

> +		kfree(entry);
> +
> +	/* There is no way to free memory allocated from bootmem*/
> +}

This function is a bit ugly - poking around in page flags to determine
whether or not the memory came from bootmem.  It would be cleaner to
use a separate boolean.  Although I guess we can live with it as you
have it here.

>  static struct kobj_type memmap_ktype = {
> +	.release	= release_firmware_map_entry,
>  	.sysfs_ops	= &memmap_attr_ops,
>  	.default_attrs	= def_attrs,
>  };
> @@ -123,6 +139,16 @@ static int firmware_map_add_entry(u64 start, u64 end,
>  	return 0;
>  }
>  
> +/**
> + * firmware_map_remove_entry() - Does the real work to remove a firmware
> + * memmap entry.
> + * @entry: removed entry.
> + **/
> +static inline void firmware_map_remove_entry(struct firmware_map_entry *entry)
> +{
> +	list_del(&entry->list);
> +}

Is there no locking  to protect that list?

>  /*
>   * Add memmap entry on sysfs
>   */
> @@ -144,6 +170,31 @@ static int add_sysfs_fw_map_entry(struct firmware_map_entry *entry)
>  	return 0;
>  }
>  
> +/*
> + * Remove memmap entry on sysfs
> + */
> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
> +{
> +	kobject_put(&entry->kobj);
> +}
> +
> +/*
> + * Search memmap entry
> + */
> +
> +struct firmware_map_entry * __meminit
> +find_firmware_map_entry(u64 start, u64 end, const char *type)

A better name would be firmware_map_find_entry().  To retain the (good)
convention that symbols exported from here all start with
"firmware_map_".

> +{
> +	struct firmware_map_entry *entry;
> +
> +	list_for_each_entry(entry, &map_entries, list)
> +		if ((entry->start == start) && (entry->end == end) &&
> +		    (!strcmp(entry->type, type)))
> +			return entry;
> +
> +	return NULL;
> +}
> +
>  /**
>   * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>   * memory hotplug.
> @@ -196,6 +247,32 @@ int __init firmware_map_add_early(u64 start, u64 end, const char *type)
>  	return firmware_map_add_entry(start, end, type, entry);
>  }
>  
> +/**
> + * firmware_map_remove() - remove a firmware mapping entry
> + * @start: Start of the memory range.
> + * @end:   End of the memory range.
> + * @type:  Type of the memory range.
> + *
> + * removes a firmware mapping entry.
> + *
> + * Returns 0 on success, or -EINVAL if no entry.
> + **/
> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
> +{
> +	struct firmware_map_entry *entry;
> +
> +	entry = find_firmware_map_entry(start, end - 1, type);
> +	if (!entry)
> +		return -EINVAL;
> +
> +	firmware_map_remove_entry(entry);
> +
> +	/* remove the memmap entry */
> +	remove_sysfs_fw_map_entry(entry);
> +
> +	return 0;
> +}

Again, the lack of locking looks bad.

> ...
>
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1052,9 +1052,9 @@ int offline_memory(u64 start, u64 size)
>  	return 0;
>  }
>  
> -int remove_memory(int nid, u64 start, u64 size)
> +int __ref remove_memory(int nid, u64 start, u64 size)

Why was __ref added?

>  {
> -	int ret = -EBUSY;
> +	int ret = 0;
>  	lock_memory_hotplug();
>  	/*
>  	 * The memory might become online by other task, even if you offine it.
>
> ...
>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: wency@cn.fujitsu.com
Cc: x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-ia64@vger.kernel.org, cmetcalf@tilera.com,
	sparclinux@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, benh@kernel.crashing.org,
	paulus@samba.org, cl@linux.com, minchan.kim@gmail.com,
	kosaki.motohiro@jp.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com
Subject: Re: [RFC v8 PATCH 08/20] memory-hotplug: remove /sys/firmware/memmap/X sysfs
Date: Fri, 31 Aug 2012 21:06:23 +0000	[thread overview]
Message-ID: <20120831140623.8d13bd2c.akpm@linux-foundation.org> (raw)
In-Reply-To: <1346148027-24468-9-git-send-email-wency@cn.fujitsu.com>

On Tue, 28 Aug 2012 18:00:15 +0800
wency@cn.fujitsu.com wrote:

> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> 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 free firmware_map_entry since there is no way to free
>        memory which is allocated by bootmem.
> 
> ....
>
> +#define to_memmap_entry(obj) container_of(obj, struct firmware_map_entry, kobj)

It would be better to implement this as an inlined C function.  That
has improved type safety and improved readability.

> +static void release_firmware_map_entry(struct kobject *kobj)
> +{
> +	struct firmware_map_entry *entry = to_memmap_entry(kobj);
> +	struct page *page;
> +
> +	page = virt_to_page(entry);
> +	if (PageSlab(page) || PageCompound(page))

That PageCompound() test looks rather odd.  Why is this done?

> +		kfree(entry);
> +
> +	/* There is no way to free memory allocated from bootmem*/
> +}

This function is a bit ugly - poking around in page flags to determine
whether or not the memory came from bootmem.  It would be cleaner to
use a separate boolean.  Although I guess we can live with it as you
have it here.

>  static struct kobj_type memmap_ktype = {
> +	.release	= release_firmware_map_entry,
>  	.sysfs_ops	= &memmap_attr_ops,
>  	.default_attrs	= def_attrs,
>  };
> @@ -123,6 +139,16 @@ static int firmware_map_add_entry(u64 start, u64 end,
>  	return 0;
>  }
>  
> +/**
> + * firmware_map_remove_entry() - Does the real work to remove a firmware
> + * memmap entry.
> + * @entry: removed entry.
> + **/
> +static inline void firmware_map_remove_entry(struct firmware_map_entry *entry)
> +{
> +	list_del(&entry->list);
> +}

Is there no locking  to protect that list?

>  /*
>   * Add memmap entry on sysfs
>   */
> @@ -144,6 +170,31 @@ static int add_sysfs_fw_map_entry(struct firmware_map_entry *entry)
>  	return 0;
>  }
>  
> +/*
> + * Remove memmap entry on sysfs
> + */
> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
> +{
> +	kobject_put(&entry->kobj);
> +}
> +
> +/*
> + * Search memmap entry
> + */
> +
> +struct firmware_map_entry * __meminit
> +find_firmware_map_entry(u64 start, u64 end, const char *type)

A better name would be firmware_map_find_entry().  To retain the (good)
convention that symbols exported from here all start with
"firmware_map_".

> +{
> +	struct firmware_map_entry *entry;
> +
> +	list_for_each_entry(entry, &map_entries, list)
> +		if ((entry->start = start) && (entry->end = end) &&
> +		    (!strcmp(entry->type, type)))
> +			return entry;
> +
> +	return NULL;
> +}
> +
>  /**
>   * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>   * memory hotplug.
> @@ -196,6 +247,32 @@ int __init firmware_map_add_early(u64 start, u64 end, const char *type)
>  	return firmware_map_add_entry(start, end, type, entry);
>  }
>  
> +/**
> + * firmware_map_remove() - remove a firmware mapping entry
> + * @start: Start of the memory range.
> + * @end:   End of the memory range.
> + * @type:  Type of the memory range.
> + *
> + * removes a firmware mapping entry.
> + *
> + * Returns 0 on success, or -EINVAL if no entry.
> + **/
> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
> +{
> +	struct firmware_map_entry *entry;
> +
> +	entry = find_firmware_map_entry(start, end - 1, type);
> +	if (!entry)
> +		return -EINVAL;
> +
> +	firmware_map_remove_entry(entry);
> +
> +	/* remove the memmap entry */
> +	remove_sysfs_fw_map_entry(entry);
> +
> +	return 0;
> +}

Again, the lack of locking looks bad.

> ...
>
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1052,9 +1052,9 @@ int offline_memory(u64 start, u64 size)
>  	return 0;
>  }
>  
> -int remove_memory(int nid, u64 start, u64 size)
> +int __ref remove_memory(int nid, u64 start, u64 size)

Why was __ref added?

>  {
> -	int ret = -EBUSY;
> +	int ret = 0;
>  	lock_memory_hotplug();
>  	/*
>  	 * The memory might become online by other task, even if you offine it.
>
> ...
>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: wency@cn.fujitsu.com
Cc: linux-s390@vger.kernel.org, linux-ia64@vger.kernel.org,
	len.brown@intel.com, linux-acpi@vger.kernel.org,
	linux-sh@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, cmetcalf@tilera.com,
	linux-mm@kvack.org, isimatu.yasuaki@jp.fujitsu.com,
	paulus@samba.org, minchan.kim@gmail.com,
	kosaki.motohiro@jp.fujitsu.com, rientjes@google.com,
	sparclinux@vger.kernel.org, cl@linux.com,
	linuxppc-dev@lists.ozlabs.org, liuj97@gmail.com
Subject: Re: [RFC v8 PATCH 08/20] memory-hotplug: remove /sys/firmware/memmap/X sysfs
Date: Fri, 31 Aug 2012 14:06:23 -0700	[thread overview]
Message-ID: <20120831140623.8d13bd2c.akpm@linux-foundation.org> (raw)
In-Reply-To: <1346148027-24468-9-git-send-email-wency@cn.fujitsu.com>

On Tue, 28 Aug 2012 18:00:15 +0800
wency@cn.fujitsu.com wrote:

> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> 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 free firmware_map_entry since there is no way to free
>        memory which is allocated by bootmem.
> 
> ....
>
> +#define to_memmap_entry(obj) container_of(obj, struct firmware_map_entry, kobj)

It would be better to implement this as an inlined C function.  That
has improved type safety and improved readability.

> +static void release_firmware_map_entry(struct kobject *kobj)
> +{
> +	struct firmware_map_entry *entry = to_memmap_entry(kobj);
> +	struct page *page;
> +
> +	page = virt_to_page(entry);
> +	if (PageSlab(page) || PageCompound(page))

That PageCompound() test looks rather odd.  Why is this done?

> +		kfree(entry);
> +
> +	/* There is no way to free memory allocated from bootmem*/
> +}

This function is a bit ugly - poking around in page flags to determine
whether or not the memory came from bootmem.  It would be cleaner to
use a separate boolean.  Although I guess we can live with it as you
have it here.

>  static struct kobj_type memmap_ktype = {
> +	.release	= release_firmware_map_entry,
>  	.sysfs_ops	= &memmap_attr_ops,
>  	.default_attrs	= def_attrs,
>  };
> @@ -123,6 +139,16 @@ static int firmware_map_add_entry(u64 start, u64 end,
>  	return 0;
>  }
>  
> +/**
> + * firmware_map_remove_entry() - Does the real work to remove a firmware
> + * memmap entry.
> + * @entry: removed entry.
> + **/
> +static inline void firmware_map_remove_entry(struct firmware_map_entry *entry)
> +{
> +	list_del(&entry->list);
> +}

Is there no locking  to protect that list?

>  /*
>   * Add memmap entry on sysfs
>   */
> @@ -144,6 +170,31 @@ static int add_sysfs_fw_map_entry(struct firmware_map_entry *entry)
>  	return 0;
>  }
>  
> +/*
> + * Remove memmap entry on sysfs
> + */
> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
> +{
> +	kobject_put(&entry->kobj);
> +}
> +
> +/*
> + * Search memmap entry
> + */
> +
> +struct firmware_map_entry * __meminit
> +find_firmware_map_entry(u64 start, u64 end, const char *type)

A better name would be firmware_map_find_entry().  To retain the (good)
convention that symbols exported from here all start with
"firmware_map_".

> +{
> +	struct firmware_map_entry *entry;
> +
> +	list_for_each_entry(entry, &map_entries, list)
> +		if ((entry->start == start) && (entry->end == end) &&
> +		    (!strcmp(entry->type, type)))
> +			return entry;
> +
> +	return NULL;
> +}
> +
>  /**
>   * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>   * memory hotplug.
> @@ -196,6 +247,32 @@ int __init firmware_map_add_early(u64 start, u64 end, const char *type)
>  	return firmware_map_add_entry(start, end, type, entry);
>  }
>  
> +/**
> + * firmware_map_remove() - remove a firmware mapping entry
> + * @start: Start of the memory range.
> + * @end:   End of the memory range.
> + * @type:  Type of the memory range.
> + *
> + * removes a firmware mapping entry.
> + *
> + * Returns 0 on success, or -EINVAL if no entry.
> + **/
> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
> +{
> +	struct firmware_map_entry *entry;
> +
> +	entry = find_firmware_map_entry(start, end - 1, type);
> +	if (!entry)
> +		return -EINVAL;
> +
> +	firmware_map_remove_entry(entry);
> +
> +	/* remove the memmap entry */
> +	remove_sysfs_fw_map_entry(entry);
> +
> +	return 0;
> +}

Again, the lack of locking looks bad.

> ...
>
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1052,9 +1052,9 @@ int offline_memory(u64 start, u64 size)
>  	return 0;
>  }
>  
> -int remove_memory(int nid, u64 start, u64 size)
> +int __ref remove_memory(int nid, u64 start, u64 size)

Why was __ref added?

>  {
> -	int ret = -EBUSY;
> +	int ret = 0;
>  	lock_memory_hotplug();
>  	/*
>  	 * The memory might become online by other task, even if you offine it.
>
> ...
>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: wency@cn.fujitsu.com
Cc: x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-ia64@vger.kernel.org, cmetcalf@tilera.com,
	sparclinux@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, benh@kernel.crashing.org,
	paulus@samba.org, cl@linux.com, minchan.kim@gmail.com,
	kosaki.motohiro@jp.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com
Subject: Re: [RFC v8 PATCH 08/20] memory-hotplug: remove /sys/firmware/memmap/X sysfs
Date: Fri, 31 Aug 2012 14:06:23 -0700	[thread overview]
Message-ID: <20120831140623.8d13bd2c.akpm@linux-foundation.org> (raw)
In-Reply-To: <1346148027-24468-9-git-send-email-wency@cn.fujitsu.com>

On Tue, 28 Aug 2012 18:00:15 +0800
wency@cn.fujitsu.com wrote:

> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> 
> 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 free firmware_map_entry since there is no way to free
>        memory which is allocated by bootmem.
> 
> ....
>
> +#define to_memmap_entry(obj) container_of(obj, struct firmware_map_entry, kobj)

It would be better to implement this as an inlined C function.  That
has improved type safety and improved readability.

> +static void release_firmware_map_entry(struct kobject *kobj)
> +{
> +	struct firmware_map_entry *entry = to_memmap_entry(kobj);
> +	struct page *page;
> +
> +	page = virt_to_page(entry);
> +	if (PageSlab(page) || PageCompound(page))

That PageCompound() test looks rather odd.  Why is this done?

> +		kfree(entry);
> +
> +	/* There is no way to free memory allocated from bootmem*/
> +}

This function is a bit ugly - poking around in page flags to determine
whether or not the memory came from bootmem.  It would be cleaner to
use a separate boolean.  Although I guess we can live with it as you
have it here.

>  static struct kobj_type memmap_ktype = {
> +	.release	= release_firmware_map_entry,
>  	.sysfs_ops	= &memmap_attr_ops,
>  	.default_attrs	= def_attrs,
>  };
> @@ -123,6 +139,16 @@ static int firmware_map_add_entry(u64 start, u64 end,
>  	return 0;
>  }
>  
> +/**
> + * firmware_map_remove_entry() - Does the real work to remove a firmware
> + * memmap entry.
> + * @entry: removed entry.
> + **/
> +static inline void firmware_map_remove_entry(struct firmware_map_entry *entry)
> +{
> +	list_del(&entry->list);
> +}

Is there no locking  to protect that list?

>  /*
>   * Add memmap entry on sysfs
>   */
> @@ -144,6 +170,31 @@ static int add_sysfs_fw_map_entry(struct firmware_map_entry *entry)
>  	return 0;
>  }
>  
> +/*
> + * Remove memmap entry on sysfs
> + */
> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry *entry)
> +{
> +	kobject_put(&entry->kobj);
> +}
> +
> +/*
> + * Search memmap entry
> + */
> +
> +struct firmware_map_entry * __meminit
> +find_firmware_map_entry(u64 start, u64 end, const char *type)

A better name would be firmware_map_find_entry().  To retain the (good)
convention that symbols exported from here all start with
"firmware_map_".

> +{
> +	struct firmware_map_entry *entry;
> +
> +	list_for_each_entry(entry, &map_entries, list)
> +		if ((entry->start == start) && (entry->end == end) &&
> +		    (!strcmp(entry->type, type)))
> +			return entry;
> +
> +	return NULL;
> +}
> +
>  /**
>   * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>   * memory hotplug.
> @@ -196,6 +247,32 @@ int __init firmware_map_add_early(u64 start, u64 end, const char *type)
>  	return firmware_map_add_entry(start, end, type, entry);
>  }
>  
> +/**
> + * firmware_map_remove() - remove a firmware mapping entry
> + * @start: Start of the memory range.
> + * @end:   End of the memory range.
> + * @type:  Type of the memory range.
> + *
> + * removes a firmware mapping entry.
> + *
> + * Returns 0 on success, or -EINVAL if no entry.
> + **/
> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
> +{
> +	struct firmware_map_entry *entry;
> +
> +	entry = find_firmware_map_entry(start, end - 1, type);
> +	if (!entry)
> +		return -EINVAL;
> +
> +	firmware_map_remove_entry(entry);
> +
> +	/* remove the memmap entry */
> +	remove_sysfs_fw_map_entry(entry);
> +
> +	return 0;
> +}

Again, the lack of locking looks bad.

> ...
>
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1052,9 +1052,9 @@ int offline_memory(u64 start, u64 size)
>  	return 0;
>  }
>  
> -int remove_memory(int nid, u64 start, u64 size)
> +int __ref remove_memory(int nid, u64 start, u64 size)

Why was __ref added?

>  {
> -	int ret = -EBUSY;
> +	int ret = 0;
>  	lock_memory_hotplug();
>  	/*
>  	 * The memory might become online by other task, even if you offine it.
>
> ...
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-08-31 21:06 UTC|newest]

Thread overview: 177+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-28 10:00 [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 01/20] memory-hotplug: rename remove_memory() to offline_memory()/offline_pages() wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 02/20] memory-hotplug: implement offline_memory() wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 03/20] memory-hotplug: store the node id in acpi_memory_device wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 04/20] memory-hotplug: offline and remove memory when removing the memory device wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-31 20:55   ` Andrew Morton
2012-08-31 20:55     ` Andrew Morton
2012-08-31 20:55     ` Andrew Morton
2012-08-31 20:55     ` Andrew Morton
2012-09-03  1:30     ` Wen Congyang
2012-09-03  1:30       ` Wen Congyang
2012-09-03  1:30       ` Wen Congyang
2012-09-03  1:30       ` Wen Congyang
2012-08-28 10:00 ` [RFC v8 PATCH 05/20] memory-hotplug: check whether memory is present or not wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 06/20] memory-hotplug: export the function acpi_bus_remove() wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 07/20] memory-hotplug: call acpi_bus_remove() to remove memory device wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 08/20] memory-hotplug: remove /sys/firmware/memmap/X sysfs wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-31 21:06   ` Andrew Morton [this message]
2012-08-31 21:06     ` Andrew Morton
2012-08-31 21:06     ` Andrew Morton
2012-08-31 21:06     ` Andrew Morton
2012-09-03  5:51     ` Wen Congyang
2012-09-03  5:51       ` Wen Congyang
2012-09-03  5:51       ` Wen Congyang
2012-09-03  5:51       ` Wen Congyang
2012-09-04 23:16       ` Andrew Morton
2012-09-04 23:16         ` Andrew Morton
2012-09-04 23:16         ` Andrew Morton
2012-09-04 23:16         ` Andrew Morton
2012-09-05  1:41         ` Wen Congyang
2012-09-05  1:41           ` Wen Congyang
2012-09-05  1:41           ` Wen Congyang
2012-09-05  1:41           ` Wen Congyang
2012-09-03  7:31     ` Wen Congyang
2012-09-03  7:31       ` Wen Congyang
2012-09-03  7:31       ` Wen Congyang
2012-09-03  7:31       ` Wen Congyang
2012-08-28 10:00 ` [RFC v8 PATCH 09/20] memory-hotplug: does not release memory region in PAGES_PER_SECTION chunks wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 10/20] memory-hotplug: add memory_block_release wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 11/20] memory-hotplug: remove_memory calls __remove_pages wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 12/20] memory-hotplug: introduce new function arch_remove_memory() wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 13/20] memory-hotplug: check page type in get_page_bootmem wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-31 21:30   ` Andrew Morton
2012-08-31 21:30     ` Andrew Morton
2012-08-31 21:30     ` Andrew Morton
2012-08-31 21:30     ` Andrew Morton
2012-09-04  3:46     ` Wen Congyang
2012-09-04  3:46       ` Wen Congyang
2012-09-04  3:46       ` Wen Congyang
2012-09-04  3:46       ` Wen Congyang
2012-09-04  9:54       ` Yasuaki Ishimatsu
2012-09-04  9:54         ` Yasuaki Ishimatsu
2012-09-04  9:54         ` Yasuaki Ishimatsu
2012-09-04  9:54         ` Yasuaki Ishimatsu
2012-08-28 10:00 ` [RFC v8 PATCH 14/20] memory-hotplug: move register_page_bootmem_info_node and put_page_bootmem for sparse-vmemmap wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` [RFC v8 PATCH 14/20] memory-hotplug: move register_page_bootmem_info_node and put_page_bootmem for s wency
2012-08-28 10:00 ` [RFC v8 PATCH 15/20] memory-hotplug: implement register_page_bootmem_info_section of sparse-vmemmap wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 16/20] memory-hotplug: free memmap " wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 17/20] memory_hotplug: clear zone when the memory is removed wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 18/20] memory-hotplug: add node_device_release wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 19/20] memory-hotplug: remove sysfs file of node wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00 ` [RFC v8 PATCH 20/20] memory-hotplug: clear hwpoisoned flag when onlining pages wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-28 10:00   ` wency
2012-08-31 20:49 ` [RFC v8 PATCH 00/20] memory-hotplug: hot-remove physical memory Andrew Morton
2012-08-31 20:49   ` Andrew Morton
2012-08-31 20:49   ` Andrew Morton
2012-08-31 20:49   ` Andrew Morton
2012-09-10  1:46   ` Yasuaki Ishimatsu
2012-09-10  1:46     ` Yasuaki Ishimatsu
2012-09-10  1:46     ` Yasuaki Ishimatsu
2012-09-10  1:46     ` Yasuaki Ishimatsu
2012-09-10  1:56     ` Wen Congyang
2012-09-10  2:01       ` Wen Congyang
2012-09-10  2:01       ` Wen Congyang
2012-09-10  2:01       ` Wen Congyang
2012-09-10  1:56       ` Wen Congyang
2012-09-10 13:52       ` Vasilis Liaskovitis
2012-09-10 13:52         ` Vasilis Liaskovitis
2012-09-10 13:52         ` Vasilis Liaskovitis
2012-09-10 13:52         ` Vasilis Liaskovitis
2012-09-11  0:27         ` Jerry
2012-09-11  0:27           ` Jerry
2012-09-11  1:23           ` Minchan Kim
2012-09-11  1:23             ` Minchan Kim
2012-09-11  1:23             ` Minchan Kim
2012-09-11  1:23             ` Minchan Kim
2012-09-11  5:18             ` Jerry
2012-09-11  5:18               ` Jerry
2012-09-11  5:39               ` Wen Congyang
2012-09-11  5:39                 ` Wen Congyang
2012-09-11  5:39                 ` Wen Congyang
2012-09-11  5:39                 ` Wen Congyang
2012-09-12  6:17               ` Minchan Kim
2012-09-12  6:17                 ` Minchan Kim
2012-09-12  6:17                 ` Minchan Kim
2012-09-12  6:17                 ` Minchan Kim
2012-09-11  1:25           ` Wen Congyang
2012-09-11  1:25             ` Wen Congyang
2012-09-11  1:25             ` Wen Congyang
2012-09-11  1:25             ` Wen Congyang
2012-09-12  5:20         ` Wen Congyang
2012-09-12  5:20           ` Wen Congyang
2012-09-12  5:20           ` Wen Congyang
2012-09-12  5:20           ` Wen Congyang
2012-09-12 17:18           ` Vasilis Liaskovitis
2012-09-12 17:18             ` Vasilis Liaskovitis
2012-09-12 17:18             ` Vasilis Liaskovitis
2012-09-12 17:18             ` Vasilis Liaskovitis
2012-09-18  9:39             ` Wen Congyang
2012-09-18  9:39               ` Wen Congyang
2012-09-18  9:39               ` Wen Congyang
2012-09-18  9:39               ` Wen Congyang
2012-09-19 17:02               ` Vasilis Liaskovitis
2012-09-19 17:02                 ` Vasilis Liaskovitis
2012-09-19 17:02                 ` Vasilis Liaskovitis
2012-09-19 17:02                 ` Vasilis Liaskovitis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120831140623.8d13bd2c.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=cl@linux.com \
    --cc=cmetcalf@tilera.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=liuj97@gmail.com \
    --cc=minchan.kim@gmail.com \
    --cc=paulus@samba.org \
    --cc=rientjes@google.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=wency@cn.fujitsu.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.