All of lore.kernel.org
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, cl@linux.com,
	minchan.kim@gmail.com, akpm@linux-foundation.org
Subject: Re: [PATCH 1/4] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove()
Date: Thu, 18 Oct 2012 15:44:38 -0400	[thread overview]
Message-ID: <CAHGf_=rxGeb0RsgEFF2FRRfdX0wiE9cDyVaftsG3E8AgyzYi1g@mail.gmail.com> (raw)
In-Reply-To: <507E77D1.3030709@cn.fujitsu.com>

>>>>> +       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 and REMOVEL_EJECT should be ignored. Why
>>>> we need remove memory here instead of ACPI_NOTIFY_EJECT_REQUEST.
>>>
>>> Hmm, we have 2 ways to remove a memory:
>>> 1. SCI
>>> 2. echo 1 >/sys/bus/acpi/devices/PNP0C80:XX/eject
>>>
>>> In the 2nd case, there is no ACPI_NOTIFY_EJECT_REQUEST. We should offline
>>> the memory and remove it from kernel in the release callback. We will poweroff
>>> the memory device in acpi_bus_hot_remove_device(), so we must offline
>>> and remove it if the type is ACPI_BUS_REMOVAL_EJECT.
>>>
>>> I guess we should not poweroff the memory device when we fail to offline it.
>>> But device_release_driver() doesn't returns any error...
>>
>> 1) I think /sys/bus/acpi/devices/PNP0C80:XX/eject should emulate acpi
>> eject. Can't
>> you make a pseudo acpi eject event and detach device by acpi regular path?
>
> It is another issue. And we only can implement it here with current acpi
> implemention. Some other acpi devices(for example: cpu) do it like this.

Hint: only cpu take like this.


>> 2) Your explanation didn't explain why we should ignore REMOVAL_NORMAL
>> and REMOVEL_EJECT. As far as reviewers can't track your intention, we
>> can't maintain
>> the code and can't ack them.
>>
>
> REMOVAL_NORMAL means the user want to unbind the memory device from this driver.
> It is no need to eject the device, and we can still use this device after unbinding.
> So it can be ignored.
>
> REMOVAL_EJECT means the user want to eject and remove the device, and we should
> not use the device. So we should offline and remove the memory here.

This is not exactly correct, IMHO. Usually, we must not touch unbinded
device because
they are out of OS control. If I understand is correct, the main
reason is to distinguish a
rollback of driver initialization failure and true ejection.

REMOVAL_NORMAL is usually used for rollback and REMOVAL_EJECT is used for
removal device eject. Typical device don't need to distinguish them
because we should
deallocate every resource even when driver initialization failure.

However, cpu and memory are exceptions. They are recognized from kernel before
driver initialization. Then even if machine have crappy acpi table and
make failure acpi
initialization, disabling memory make no sense.

And, when you make _exceptional_ rule, you should comment verbosely in the code
the detail.  likes 1) why we need.  2) which
device/machine/environment suffer such exception. 2)  what affect
other subsys.

Even though cpu hotplug has crappy poor comment and document, please
don't follow
them.

WARNING: multiple messages have this Message-ID (diff)
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, cl@linux.com,
	minchan.kim@gmail.com, akpm@linux-foundation.org
Subject: Re: [PATCH 1/4] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove()
Date: Thu, 18 Oct 2012 15:44:38 -0400	[thread overview]
Message-ID: <CAHGf_=rxGeb0RsgEFF2FRRfdX0wiE9cDyVaftsG3E8AgyzYi1g@mail.gmail.com> (raw)
In-Reply-To: <507E77D1.3030709@cn.fujitsu.com>

>>>>> +       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 and REMOVEL_EJECT should be ignored. Why
>>>> we need remove memory here instead of ACPI_NOTIFY_EJECT_REQUEST.
>>>
>>> Hmm, we have 2 ways to remove a memory:
>>> 1. SCI
>>> 2. echo 1 >/sys/bus/acpi/devices/PNP0C80:XX/eject
>>>
>>> In the 2nd case, there is no ACPI_NOTIFY_EJECT_REQUEST. We should offline
>>> the memory and remove it from kernel in the release callback. We will poweroff
>>> the memory device in acpi_bus_hot_remove_device(), so we must offline
>>> and remove it if the type is ACPI_BUS_REMOVAL_EJECT.
>>>
>>> I guess we should not poweroff the memory device when we fail to offline it.
>>> But device_release_driver() doesn't returns any error...
>>
>> 1) I think /sys/bus/acpi/devices/PNP0C80:XX/eject should emulate acpi
>> eject. Can't
>> you make a pseudo acpi eject event and detach device by acpi regular path?
>
> It is another issue. And we only can implement it here with current acpi
> implemention. Some other acpi devices(for example: cpu) do it like this.

Hint: only cpu take like this.


>> 2) Your explanation didn't explain why we should ignore REMOVAL_NORMAL
>> and REMOVEL_EJECT. As far as reviewers can't track your intention, we
>> can't maintain
>> the code and can't ack them.
>>
>
> REMOVAL_NORMAL means the user want to unbind the memory device from this driver.
> It is no need to eject the device, and we can still use this device after unbinding.
> So it can be ignored.
>
> REMOVAL_EJECT means the user want to eject and remove the device, and we should
> not use the device. So we should offline and remove the memory here.

This is not exactly correct, IMHO. Usually, we must not touch unbinded
device because
they are out of OS control. If I understand is correct, the main
reason is to distinguish a
rollback of driver initialization failure and true ejection.

REMOVAL_NORMAL is usually used for rollback and REMOVAL_EJECT is used for
removal device eject. Typical device don't need to distinguish them
because we should
deallocate every resource even when driver initialization failure.

However, cpu and memory are exceptions. They are recognized from kernel before
driver initialization. Then even if machine have crappy acpi table and
make failure acpi
initialization, disabling memory make no sense.

And, when you make _exceptional_ rule, you should comment verbosely in the code
the detail.  likes 1) why we need.  2) which
device/machine/environment suffer such exception. 2)  what affect
other subsys.

Even though cpu hotplug has crappy poor comment and document, please
don't follow
them.

--
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-10-18 19:44 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03  9:52 [PATCH 0/4] acpi,memory-hotplug : implement framework for hot removing memory Yasuaki Ishimatsu
2012-10-03  9:52 ` Yasuaki Ishimatsu
2012-10-03  9:52 ` Yasuaki Ishimatsu
2012-10-03  9:58 ` [PATCH 1/4] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove() Yasuaki Ishimatsu
2012-10-03  9:58   ` Yasuaki Ishimatsu
2012-10-04 20:53   ` KOSAKI Motohiro
2012-10-04 20:53     ` KOSAKI Motohiro
2012-10-08  6:58     ` Wen Congyang
2012-10-08  6:58       ` Wen Congyang
2012-10-12 19:10       ` KOSAKI Motohiro
2012-10-12 19:10         ` KOSAKI Motohiro
2012-10-17  6:48         ` Wen Congyang
2012-10-17  6:48           ` Wen Congyang
2012-10-17  8:59           ` KOSAKI Motohiro
2012-10-17  8:59             ` KOSAKI Motohiro
2012-10-17  9:08             ` Wen Congyang
2012-10-17  9:08               ` Wen Congyang
2012-10-17  9:18               ` KOSAKI Motohiro
2012-10-17  9:18                 ` KOSAKI Motohiro
2012-10-17  9:52                 ` Wen Congyang
2012-10-17  9:52                   ` Wen Congyang
2012-10-18  1:25                   ` Yasuaki Ishimatsu
2012-10-18  1:25                     ` Yasuaki Ishimatsu
2012-10-18  1:25                     ` Yasuaki Ishimatsu
2012-10-19  7:35                     ` Wen Congyang
2012-10-19  7:35                       ` Wen Congyang
2012-10-17  9:18         ` Wen Congyang
2012-10-17  9:18           ` Wen Congyang
2012-10-18 19:44           ` KOSAKI Motohiro [this message]
2012-10-18 19:44             ` KOSAKI Motohiro
2012-10-19  9:08             ` Wen Congyang
2012-10-19  9:08               ` Wen Congyang
2012-10-19 18:19               ` KOSAKI Motohiro
2012-10-19 18:19                 ` KOSAKI Motohiro
2012-10-20  5:02                 ` Wen Congyang
2012-10-20  5:02                   ` Wen Congyang
2012-10-22 15:11                   ` KOSAKI Motohiro
2012-10-22 15:11                     ` KOSAKI Motohiro
2012-10-22 15:34                     ` KOSAKI Motohiro
2012-10-22 15:34                       ` KOSAKI Motohiro
2012-10-03 10:02 ` [PATCH 2/4] acpi,memory-hotplug : rename remove_memory() to offline_memory() Yasuaki Ishimatsu
2012-10-03 10:02   ` Yasuaki Ishimatsu
2012-10-04 21:31   ` KOSAKI Motohiro
2012-10-04 21:31     ` KOSAKI Motohiro
2012-10-08  6:45     ` Wen Congyang
2012-10-08  6:45       ` Wen Congyang
2012-10-12 18:57       ` KOSAKI Motohiro
2012-10-12 18:57         ` KOSAKI Motohiro
2012-10-03 10:09 ` [PATCH 3/6] acpi,memory-hotplug : add physical memory hotplug code to acpi_memhotplug.c Yasuaki Ishimatsu
2012-10-03 10:09   ` Yasuaki Ishimatsu
2012-10-05 18:54   ` KOSAKI Motohiro
2012-10-05 18:54     ` KOSAKI Motohiro
2012-10-03 10:11 ` [PATCH 4/4] acpi,memory-hotplug : store the node id in acpi_memory_device Yasuaki Ishimatsu
2012-10-03 10:11   ` Yasuaki Ishimatsu
2012-10-03 10:11   ` Yasuaki Ishimatsu
2012-10-05 18:56   ` KOSAKI Motohiro
2012-10-05 18:56     ` KOSAKI Motohiro
2012-10-08  6:47     ` Wen Congyang
2012-10-08  6:47       ` Wen Congyang
2012-10-12 18:59       ` KOSAKI Motohiro
2012-10-12 18:59         ` KOSAKI Motohiro
2012-10-06 14:22 ` [PATCH 0/4] acpi,memory-hotplug : implement framework for hot removing memory Ni zhan Chen
2012-10-06 14:22   ` Ni zhan Chen

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='CAHGf_=rxGeb0RsgEFF2FRRfdX0wiE9cDyVaftsG3E8AgyzYi1g@mail.gmail.com' \
    --to=kosaki.motohiro@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuj97@gmail.com \
    --cc=minchan.kim@gmail.com \
    --cc=rientjes@google.com \
    --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.