Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1701382 > unrolled thread

Re: A udev rule to serve the change event of ACPI container?

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: A udev rule to serve the change event of ACPI container? YASUAKI ISHIMATSU <yasu.isimatu@gmail.com> - 2017-08-01 21:30 +0200
    Re: A udev rule to serve the change event of ACPI container? joeyli <jlee@suse.com> - 2017-08-02 07:50 +0200
      Re: A udev rule to serve the change event of ACPI container? YASUAKI ISHIMATSU <yasu.isimatu@gmail.com> - 2017-08-03 17:40 +0200
        Re: A udev rule to serve the change event of ACPI container? Michal Hocko <mhocko@kernel.org> - 2017-08-04 17:10 +0200

#1701382 — Re: A udev rule to serve the change event of ACPI container?

Hi Joey,

On 07/23/2017 05:18 AM, joeyli wrote:
> Hi Yasuaki,  
> 
> On Fri, Jul 14, 2017 at 10:44:14PM +0800, joeyli wrote:
>> On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote:
>>> On Thu 13-07-17 20:45:21, Joey Lee wrote:
>>>> On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote:
>>>>> On Thu 13-07-17 14:58:06, Joey Lee wrote:
>>> [...]
>>>>>> If BIOS emits ejection event for a ACPI0004 container, someone needs
>>>>>> to handle the offline/eject jobs of container. Either kernel or user
>>>>>> space.
>>>>>>
>>>>>> Only sending uevent to individual child device can simplify udev rule,
>>>>>> but it also means that the kernel needs to offline/eject container
>>>>>> after all children devices are offlined.
>>>>>
>>>>> Why cannot kernel send this eject command to the BIOS if the whole
>>>>> container is offline? If it is not then the kernel would send EBUSY to
>>>>
>>>> Current kernel container hot-remove process:
>>>>
>>>>   BIOS -> SCI event -> Kernel ACPI -> uevent -> userland
>>>>               
>>>> Then, kernel just calls _OST to expose state to BIOS, then process is
>>>> stopped. Kernel doesn't wait there for userland to offline each child
>>>> devices. Either BIOS or userland needs to trigger the container
>>>> ejection.
>>>>
>>>>> container is offline? If it is not then the kernel would send EBUSY to
>>>>> the BIOS and BIOS would have to retry after some timeout. Or is it a
>>>>
>>>> The d429e5c122 patch is merged to mainline. So kernel will send
>>>> DEVICE_BUSY to BIOS after it emits uevent to userland. BIOS can choice
>>>> to apply the retry approach until OS returns process failure exactly or
>>>> BIOS timeout.
>>>>
>>>>> problem that currently implemented BIOS firmwares do not implement this
>>>>> retry?
>>>>
>>>> Yes, we should consider the behavior of old BIOS. Old BIOS doesn't
>>>> retry/resend the ejection event. So kernel or userland need to take the
>>>> retry job. Obviously userland runs the retry since the caa73ea15 patch
>>>> is merged.
>>>>
>>>> IMHO there have two different expectation from user space application.
>>>>
>>>> Applications like DVD player or Burner expect that kernel should
>>>> info userspace for the ejection, then application can do their cleaning
>>>> job and re-trigger ejection from userland.
>>>
>>> I am not sure I understand the DVD example because I do not see how it
>>> fits into the container and online/offline scenario.
>>>
>>
>> At least Yasuaki raised similar behavior for container in 2013.
>> It's similar to the DVD player case, user space application needs
>> to do something then trigger children offline and ejection of
>> container.
>>
>> Base on Yasuaki's explanation, the reason of that he requested the
>> userland ejection approach is that he got memory hot-remove problem
>> in 2013. Maybe his problem is already fixed by your patches in current
>> mainline.
>>
>> Hi Yasuaki, could you please check that your memory hot-remove problem
>> is fixed on mainline kernel?  

I cannot remember what I mentioned in 2013. Could you tell me url of lkml archive.

Thanks,
Yasuaki Ishimatsu

>>
>> If Yasuaki's issue is already fixed, then we should consider to let
>> kernel does the container hot-remove transparently. 
> 
> Could you please help to check that your memory hot-remove problem in 2013
> is fixed on mainline kernel?  
> 
> Thanks a lot!
> Joey Lee
> 

[toc] | [next] | [standalone]

#1701736

Hi YASUAKI,

On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI ISHIMATSU wrote:
> Hi Joey,
> 
> On 07/23/2017 05:18 AM, joeyli wrote:
[...snip]
> >>>
> >>
> >> At least Yasuaki raised similar behavior for container in 2013.
> >> It's similar to the DVD player case, user space application needs
> >> to do something then trigger children offline and ejection of
> >> container.
> >>
> >> Base on Yasuaki's explanation, the reason of that he requested the
> >> userland ejection approach is that he got memory hot-remove problem
> >> in 2013. Maybe his problem is already fixed by your patches in current
> >> mainline.
> >>
> >> Hi Yasuaki, could you please check that your memory hot-remove problem
> >> is fixed on mainline kernel?  
> 
> I cannot remember what I mentioned in 2013. Could you tell me url of lkml archive.
>

Here: https://lkml.org/lkml/2013/11/28/520

In the mail, you mentioned two problems. But there have no detail about
those issues, and no root causes. We don't know why kernel should relies
on user space to complete the hot removing process for container.

Thank a lot!
Joey Lee

[toc] | [prev] | [next] | [standalone]

#1703204

On 08/02/2017 01:49 AM, joeyli wrote:
> Hi YASUAKI,
> 
> On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI ISHIMATSU wrote:
>> Hi Joey,
>>
>> On 07/23/2017 05:18 AM, joeyli wrote:
> [...snip]
>>>>>
>>>>
>>>> At least Yasuaki raised similar behavior for container in 2013.
>>>> It's similar to the DVD player case, user space application needs
>>>> to do something then trigger children offline and ejection of
>>>> container.
>>>>
>>>> Base on Yasuaki's explanation, the reason of that he requested the
>>>> userland ejection approach is that he got memory hot-remove problem
>>>> in 2013. Maybe his problem is already fixed by your patches in current
>>>> mainline.
>>>>
>>>> Hi Yasuaki, could you please check that your memory hot-remove problem
>>>> is fixed on mainline kernel?  
>>
>> I cannot remember what I mentioned in 2013. Could you tell me url of lkml archive.
>>
> 

> Here: https://lkml.org/lkml/2013/11/28/520

Thank you for specifying the URL. In the URL, I wrote the following problems:

>   1. easily fail
>      My container device has CPU device and Memory device, and maximum size of
>      memory is 3Tbyte. In my environment, hot removing container device fails
>      on offlining memory if memory is used by application.
>      I think if offlininig memory, we must retly to offline memory several
>      times.

I think the issue still remains. If process keeps accessing memory, offlining
the memory easily fails with EBUSY.

Thanks,
Yasuaki Ishimatsu


> 
> In the mail, you mentioned two problems. But there have no detail about
> those issues, and no root causes. We don't know why kernel should relies
> on user space to complete the hot removing process for container.
> 
> Thank a lot!
> Joey Lee
> 

[toc] | [prev] | [next] | [standalone]

#1704065

On Thu 03-08-17 11:37:37, YASUAKI ISHIMATSU wrote:
> 
> 
> On 08/02/2017 01:49 AM, joeyli wrote:
> > Hi YASUAKI,
> > 
> > On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI ISHIMATSU wrote:
> >> Hi Joey,
> >>
> >> On 07/23/2017 05:18 AM, joeyli wrote:
> > [...snip]
> >>>>>
> >>>>
> >>>> At least Yasuaki raised similar behavior for container in 2013.
> >>>> It's similar to the DVD player case, user space application needs
> >>>> to do something then trigger children offline and ejection of
> >>>> container.
> >>>>
> >>>> Base on Yasuaki's explanation, the reason of that he requested the
> >>>> userland ejection approach is that he got memory hot-remove problem
> >>>> in 2013. Maybe his problem is already fixed by your patches in current
> >>>> mainline.
> >>>>
> >>>> Hi Yasuaki, could you please check that your memory hot-remove problem
> >>>> is fixed on mainline kernel?  
> >>
> >> I cannot remember what I mentioned in 2013. Could you tell me url of lkml archive.
> >>
> > 
> 
> > Here: https://lkml.org/lkml/2013/11/28/520
> 
> Thank you for specifying the URL. In the URL, I wrote the following problems:
> 
> >   1. easily fail
> >      My container device has CPU device and Memory device, and maximum size of
> >      memory is 3Tbyte. In my environment, hot removing container device fails
> >      on offlining memory if memory is used by application.
> >      I think if offlininig memory, we must retly to offline memory several
> >      times.
> 
> I think the issue still remains. If process keeps accessing memory, offlining
> the memory easily fails with EBUSY.

Yes and the only way how to deal with it is to retry the offline. In
order to do that userspace has to be notified to try again.
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web