Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-20 Thread Xunlei Pang 
On 12/19/2016 at 11:23 AM, Baoquan He wrote:
> On 12/09/16 at 03:16pm, Xunlei Pang wrote:
>> On 12/09/2016 at 01:13 PM, zhong jiang wrote:
>>> On 2016/12/8 17:41, Xunlei Pang wrote:
 On 12/08/2016 at 10:37 AM, zhongjiang wrote:
> From: zhong jiang 
>
> A soft lookup will occur when I run trinity in syscall kexec_load.
> the corresponding stack information is as follows.
>
> [  237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
> [  237.242699] Kernel panic - not syncing: softlockup: hung tasks
> [  237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G   O 
> L V---   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
> [  237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 
> V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
> [  237.269752]  8187626b 18cfde31 88184c803e18 
> 81638f16
> [  237.277471]  88184c803e98 8163278f 0008 
> 88184c803ea8
> [  237.285190]  88184c803e48 18cfde31 88184c803e67 
> 
> [  237.292909] Call Trace:
> [  237.295404][] dump_stack+0x19/0x1b
> [  237.301352]  [] panic+0xd8/0x214
> [  237.306196]  [] watchdog_timer_fn+0x1cc/0x1e0
> [  237.312157]  [] ? watchdog_enable+0xc0/0xc0
> [  237.317955]  [] __hrtimer_run_queues+0xd2/0x260
> [  237.324087]  [] hrtimer_interrupt+0xb0/0x1e0
> [  237.329963]  [] ? call_softirq+0x1c/0x30
> [  237.335500]  [] local_apic_timer_interrupt+0x37/0x60
> [  237.342228]  [] smp_apic_timer_interrupt+0x3f/0x60
> [  237.348771]  [] apic_timer_interrupt+0x6d/0x80
> [  237.354967][] ? 
> kimage_alloc_control_pages+0x80/0x270
> [  237.362875]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
> [  237.369592]  [] ? do_kimage_alloc_init+0x1f/0x90
> [  237.375992]  [] kimage_alloc_init+0x12a/0x180
> [  237.382103]  [] SyS_kexec_load+0x20a/0x260
> [  237.387957]  [] system_call_fastpath+0x16/0x1b
>
> the first time allocate control pages may take too much time because
> crash_res.end can be set to a higher value. we need to add cond_resched
> to avoid the issue.
>
> The patch have been tested and above issue is not appear.
>
> Signed-off-by: zhong jiang 
> ---
>  kernel/kexec_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 5616755..bfc9621 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -441,6 +441,8 @@ static struct page 
> *kimage_alloc_crash_control_pages(struct kimage *image,
>   while (hole_end <= crashk_res.end) {
>   unsigned long i;
>  
> + cond_resched();
> +
 I can't see why it would take a long time to loop inside, the job it does 
 is simply to find a control area
 not overlapped with image->segment[], you can see the loop "for (i = 0; i 
 < image->nr_segments; i++)",
 @hole_end will be advanced to the end of its next nearby segment once 
 overlap was detected each loop,
 also there are limited (<=16) segments, so it won't take long to locate 
 the right area.

 Am I missing something?

 Regards,
 Xunlei
>>>   if the crashkernel = auto is set in cmdline.  it represent crashk_res.end 
>>> will exceed to 4G, the first allocate control pages will
>>>   loop  million times. if we set crashk_res.end to the higher value 
>>> manually,  you can image
>> How does "loop million times" happen? See my inlined comments prefixed with 
>> "pxl".
>>
>> kimage_alloc_crash_control_pages():
>> while (hole_end <= crashk_res.end) {
>> unsigned long i;
>>
>> if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT)
>> break;
>> /* See if I overlap any of the segments */
>> for (i = 0; i < image->nr_segments; i++) {  // pxl: max 16 loops, 
>> all existent segments are not overlapped, though may not sorted.
>> unsigned long mstart, mend;
>>
>> mstart = image->segment[i].mem;
>> mend   = mstart + image->segment[i].memsz - 1;
>> if ((hole_end >= mstart) && (hole_start <= mend)) {
>> /* Advance the hole to the end of the segment */
>> hole_start = (mend + (size - 1)) & ~(size - 1);
>> hole_end   = hole_start + size - 1;
>> break;  // pxl: If overlap was found, break for loop, 
>> @hole_end starts after the overlapped segment area, and will while loop again
>> }
>> }
>> /* If I don't overlap any segments I have found my hole! */
>> if (i == image->nr_segments) {
>> pages = pfn_to_page(hole_start >> PAGE_SHIFT);
>> image->control_page = hole_end;
>> break;   // pxl: no overlap with all the segments, get

Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-18 Thread Baoquan He 
On 12/09/16 at 03:16pm, Xunlei Pang wrote:
> On 12/09/2016 at 01:13 PM, zhong jiang wrote:
> > On 2016/12/8 17:41, Xunlei Pang wrote:
> >> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
> >>> From: zhong jiang 
> >>>
> >>> A soft lookup will occur when I run trinity in syscall kexec_load.
> >>> the corresponding stack information is as follows.
> >>>
> >>> [  237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
> >>> [  237.242699] Kernel panic - not syncing: softlockup: hung tasks
> >>> [  237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G   O 
> >>> L V---   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
> >>> [  237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 
> >>> V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
> >>> [  237.269752]  8187626b 18cfde31 88184c803e18 
> >>> 81638f16
> >>> [  237.277471]  88184c803e98 8163278f 0008 
> >>> 88184c803ea8
> >>> [  237.285190]  88184c803e48 18cfde31 88184c803e67 
> >>> 
> >>> [  237.292909] Call Trace:
> >>> [  237.295404][] dump_stack+0x19/0x1b
> >>> [  237.301352]  [] panic+0xd8/0x214
> >>> [  237.306196]  [] watchdog_timer_fn+0x1cc/0x1e0
> >>> [  237.312157]  [] ? watchdog_enable+0xc0/0xc0
> >>> [  237.317955]  [] __hrtimer_run_queues+0xd2/0x260
> >>> [  237.324087]  [] hrtimer_interrupt+0xb0/0x1e0
> >>> [  237.329963]  [] ? call_softirq+0x1c/0x30
> >>> [  237.335500]  [] local_apic_timer_interrupt+0x37/0x60
> >>> [  237.342228]  [] smp_apic_timer_interrupt+0x3f/0x60
> >>> [  237.348771]  [] apic_timer_interrupt+0x6d/0x80
> >>> [  237.354967][] ? 
> >>> kimage_alloc_control_pages+0x80/0x270
> >>> [  237.362875]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
> >>> [  237.369592]  [] ? do_kimage_alloc_init+0x1f/0x90
> >>> [  237.375992]  [] kimage_alloc_init+0x12a/0x180
> >>> [  237.382103]  [] SyS_kexec_load+0x20a/0x260
> >>> [  237.387957]  [] system_call_fastpath+0x16/0x1b
> >>>
> >>> the first time allocate control pages may take too much time because
> >>> crash_res.end can be set to a higher value. we need to add cond_resched
> >>> to avoid the issue.
> >>>
> >>> The patch have been tested and above issue is not appear.
> >>>
> >>> Signed-off-by: zhong jiang 
> >>> ---
> >>>  kernel/kexec_core.c | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> >>> index 5616755..bfc9621 100644
> >>> --- a/kernel/kexec_core.c
> >>> +++ b/kernel/kexec_core.c
> >>> @@ -441,6 +441,8 @@ static struct page 
> >>> *kimage_alloc_crash_control_pages(struct kimage *image,
> >>>   while (hole_end <= crashk_res.end) {
> >>>   unsigned long i;
> >>>  
> >>> + cond_resched();
> >>> +
> >> I can't see why it would take a long time to loop inside, the job it does 
> >> is simply to find a control area
> >> not overlapped with image->segment[], you can see the loop "for (i = 0; i 
> >> < image->nr_segments; i++)",
> >> @hole_end will be advanced to the end of its next nearby segment once 
> >> overlap was detected each loop,
> >> also there are limited (<=16) segments, so it won't take long to locate 
> >> the right area.
> >>
> >> Am I missing something?
> >>
> >> Regards,
> >> Xunlei
> >   if the crashkernel = auto is set in cmdline.  it represent crashk_res.end 
> > will exceed to 4G, the first allocate control pages will
> >   loop  million times. if we set crashk_res.end to the higher value 
> > manually,  you can image
> 
> How does "loop million times" happen? See my inlined comments prefixed with 
> "pxl".
> 
> kimage_alloc_crash_control_pages():
> while (hole_end <= crashk_res.end) {
> unsigned long i;
> 
> if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT)
> break;
> /* See if I overlap any of the segments */
> for (i = 0; i < image->nr_segments; i++) {  // pxl: max 16 loops, all 
> existent segments are not overlapped, though may not sorted.
> unsigned long mstart, mend;
> 
> mstart = image->segment[i].mem;
> mend   = mstart + image->segment[i].memsz - 1;
> if ((hole_end >= mstart) && (hole_start <= mend)) {
> /* Advance the hole to the end of the segment */
> hole_start = (mend + (size - 1)) & ~(size - 1);
> hole_end   = hole_start + size - 1;
> break;  // pxl: If overlap was found, break for loop, 
> @hole_end starts after the overlapped segment area, and will while loop again
> }
> }
> /* If I don't overlap any segments I have found my hole! */
> if (i == image->nr_segments) {
> pages = pfn_to_page(hole_start >> PAGE_SHIFT);
> image->control_page = hole_end;
> break;   // pxl: no overlap with all the segments, get the result 
> and break the while loop. END.
> }   
> }
> 
>

Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-08 Thread Xunlei Pang 
On 12/09/2016 at 01:13 PM, zhong jiang wrote:
> On 2016/12/8 17:41, Xunlei Pang wrote:
>> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
>>> From: zhong jiang 
>>>
>>> A soft lookup will occur when I run trinity in syscall kexec_load.
>>> the corresponding stack information is as follows.
>>>
>>> [  237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
>>> [  237.242699] Kernel panic - not syncing: softlockup: hung tasks
>>> [  237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G   O L 
>>> V---   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
>>> [  237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 
>>> V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
>>> [  237.269752]  8187626b 18cfde31 88184c803e18 
>>> 81638f16
>>> [  237.277471]  88184c803e98 8163278f 0008 
>>> 88184c803ea8
>>> [  237.285190]  88184c803e48 18cfde31 88184c803e67 
>>> 
>>> [  237.292909] Call Trace:
>>> [  237.295404][] dump_stack+0x19/0x1b
>>> [  237.301352]  [] panic+0xd8/0x214
>>> [  237.306196]  [] watchdog_timer_fn+0x1cc/0x1e0
>>> [  237.312157]  [] ? watchdog_enable+0xc0/0xc0
>>> [  237.317955]  [] __hrtimer_run_queues+0xd2/0x260
>>> [  237.324087]  [] hrtimer_interrupt+0xb0/0x1e0
>>> [  237.329963]  [] ? call_softirq+0x1c/0x30
>>> [  237.335500]  [] local_apic_timer_interrupt+0x37/0x60
>>> [  237.342228]  [] smp_apic_timer_interrupt+0x3f/0x60
>>> [  237.348771]  [] apic_timer_interrupt+0x6d/0x80
>>> [  237.354967][] ? 
>>> kimage_alloc_control_pages+0x80/0x270
>>> [  237.362875]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
>>> [  237.369592]  [] ? do_kimage_alloc_init+0x1f/0x90
>>> [  237.375992]  [] kimage_alloc_init+0x12a/0x180
>>> [  237.382103]  [] SyS_kexec_load+0x20a/0x260
>>> [  237.387957]  [] system_call_fastpath+0x16/0x1b
>>>
>>> the first time allocate control pages may take too much time because
>>> crash_res.end can be set to a higher value. we need to add cond_resched
>>> to avoid the issue.
>>>
>>> The patch have been tested and above issue is not appear.
>>>
>>> Signed-off-by: zhong jiang 
>>> ---
>>>  kernel/kexec_core.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>>> index 5616755..bfc9621 100644
>>> --- a/kernel/kexec_core.c
>>> +++ b/kernel/kexec_core.c
>>> @@ -441,6 +441,8 @@ static struct page 
>>> *kimage_alloc_crash_control_pages(struct kimage *image,
>>> while (hole_end <= crashk_res.end) {
>>> unsigned long i;
>>>  
>>> +   cond_resched();
>>> +
>> I can't see why it would take a long time to loop inside, the job it does is 
>> simply to find a control area
>> not overlapped with image->segment[], you can see the loop "for (i = 0; i < 
>> image->nr_segments; i++)",
>> @hole_end will be advanced to the end of its next nearby segment once 
>> overlap was detected each loop,
>> also there are limited (<=16) segments, so it won't take long to locate the 
>> right area.
>>
>> Am I missing something?
>>
>> Regards,
>> Xunlei
>   if the crashkernel = auto is set in cmdline.  it represent crashk_res.end 
> will exceed to 4G, the first allocate control pages will
>   loop  million times. if we set crashk_res.end to the higher value manually, 
>  you can image

How does "loop million times" happen? See my inlined comments prefixed with 
"pxl".

kimage_alloc_crash_control_pages():
while (hole_end <= crashk_res.end) {
unsigned long i;

if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT)
break;
/* See if I overlap any of the segments */
for (i = 0; i < image->nr_segments; i++) {  // pxl: max 16 loops, all 
existent segments are not overlapped, though may not sorted.
unsigned long mstart, mend;

mstart = image->segment[i].mem;
mend   = mstart + image->segment[i].memsz - 1;
if ((hole_end >= mstart) && (hole_start <= mend)) {
/* Advance the hole to the end of the segment */
hole_start = (mend + (size - 1)) & ~(size - 1);
hole_end   = hole_start + size - 1;
break;  // pxl: If overlap was found, break for loop, @hole_end 
starts after the overlapped segment area, and will while loop again
}
}
/* If I don't overlap any segments I have found my hole! */
if (i == image->nr_segments) {
pages = pfn_to_page(hole_start >> PAGE_SHIFT);
image->control_page = hole_end;
break;   // pxl: no overlap with all the segments, get the result 
and break the while loop. END.
}   
}

So, the worst "while" loops in theory would be (image->nr_segments + 1), no?

Regards,
Xunlei

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-08 Thread zhong jiang 
On 2016/12/9 13:19, Eric W. Biederman wrote:
> zhong jiang  writes:
>
>> On 2016/12/8 17:41, Xunlei Pang wrote:
>>> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
 From: zhong jiang 

> [snip]
 diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
 index 5616755..bfc9621 100644
 --- a/kernel/kexec_core.c
 +++ b/kernel/kexec_core.c
 @@ -441,6 +441,8 @@ static struct page 
 *kimage_alloc_crash_control_pages(struct kimage *image,
while (hole_end <= crashk_res.end) {
unsigned long i;
  
 +  cond_resched();
 +
>>> I can't see why it would take a long time to loop inside, the job it does 
>>> is simply to find a control area
>>> not overlapped with image->segment[], you can see the loop "for (i = 0; i < 
>>> image->nr_segments; i++)",
>>> @hole_end will be advanced to the end of its next nearby segment once 
>>> overlap was detected each loop,
>>> also there are limited (<=16) segments, so it won't take long to locate the 
>>> right area.
>>>
>>> Am I missing something?
>>>
>>> Regards,
>>> Xunlei
>>   if the crashkernel = auto is set in cmdline.  it represent crashk_res.end 
>> will exceed to 4G, the first allocate control pages will
>>   loop  million times. if we set crashk_res.end to the higher value
>>   manually,  you can image
> Or in short the cond_resched is about keeping things reasonable when the
> loop has worst case behavior.
>
> Eric
>
>
  Yes,   Thank you reply and comment.

  Regards,
  zhongjiang


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-08 Thread Eric W. Biederman 
zhong jiang  writes:

> On 2016/12/8 17:41, Xunlei Pang wrote:
>> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
>>> From: zhong jiang 
>>>
[snip]
>>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>>> index 5616755..bfc9621 100644
>>> --- a/kernel/kexec_core.c
>>> +++ b/kernel/kexec_core.c
>>> @@ -441,6 +441,8 @@ static struct page 
>>> *kimage_alloc_crash_control_pages(struct kimage *image,
>>> while (hole_end <= crashk_res.end) {
>>> unsigned long i;
>>>  
>>> +   cond_resched();
>>> +
>> I can't see why it would take a long time to loop inside, the job it does is 
>> simply to find a control area
>> not overlapped with image->segment[], you can see the loop "for (i = 0; i < 
>> image->nr_segments; i++)",
>> @hole_end will be advanced to the end of its next nearby segment once 
>> overlap was detected each loop,
>> also there are limited (<=16) segments, so it won't take long to locate the 
>> right area.
>>
>> Am I missing something?
>>
>> Regards,
>> Xunlei
>   if the crashkernel = auto is set in cmdline.  it represent crashk_res.end 
> will exceed to 4G, the first allocate control pages will
>   loop  million times. if we set crashk_res.end to the higher value
>   manually,  you can image

Or in short the cond_resched is about keeping things reasonable when the
loop has worst case behavior.

Eric

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-08 Thread zhong jiang 
On 2016/12/8 17:41, Xunlei Pang wrote:
> On 12/08/2016 at 10:37 AM, zhongjiang wrote:
>> From: zhong jiang 
>>
>> A soft lookup will occur when I run trinity in syscall kexec_load.
>> the corresponding stack information is as follows.
>>
>> [  237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
>> [  237.242699] Kernel panic - not syncing: softlockup: hung tasks
>> [  237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G   O L 
>> V---   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
>> [  237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 
>> V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
>> [  237.269752]  8187626b 18cfde31 88184c803e18 
>> 81638f16
>> [  237.277471]  88184c803e98 8163278f 0008 
>> 88184c803ea8
>> [  237.285190]  88184c803e48 18cfde31 88184c803e67 
>> 
>> [  237.292909] Call Trace:
>> [  237.295404][] dump_stack+0x19/0x1b
>> [  237.301352]  [] panic+0xd8/0x214
>> [  237.306196]  [] watchdog_timer_fn+0x1cc/0x1e0
>> [  237.312157]  [] ? watchdog_enable+0xc0/0xc0
>> [  237.317955]  [] __hrtimer_run_queues+0xd2/0x260
>> [  237.324087]  [] hrtimer_interrupt+0xb0/0x1e0
>> [  237.329963]  [] ? call_softirq+0x1c/0x30
>> [  237.335500]  [] local_apic_timer_interrupt+0x37/0x60
>> [  237.342228]  [] smp_apic_timer_interrupt+0x3f/0x60
>> [  237.348771]  [] apic_timer_interrupt+0x6d/0x80
>> [  237.354967][] ? 
>> kimage_alloc_control_pages+0x80/0x270
>> [  237.362875]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
>> [  237.369592]  [] ? do_kimage_alloc_init+0x1f/0x90
>> [  237.375992]  [] kimage_alloc_init+0x12a/0x180
>> [  237.382103]  [] SyS_kexec_load+0x20a/0x260
>> [  237.387957]  [] system_call_fastpath+0x16/0x1b
>>
>> the first time allocate control pages may take too much time because
>> crash_res.end can be set to a higher value. we need to add cond_resched
>> to avoid the issue.
>>
>> The patch have been tested and above issue is not appear.
>>
>> Signed-off-by: zhong jiang 
>> ---
>>  kernel/kexec_core.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index 5616755..bfc9621 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -441,6 +441,8 @@ static struct page 
>> *kimage_alloc_crash_control_pages(struct kimage *image,
>>  while (hole_end <= crashk_res.end) {
>>  unsigned long i;
>>  
>> +cond_resched();
>> +
> I can't see why it would take a long time to loop inside, the job it does is 
> simply to find a control area
> not overlapped with image->segment[], you can see the loop "for (i = 0; i < 
> image->nr_segments; i++)",
> @hole_end will be advanced to the end of its next nearby segment once overlap 
> was detected each loop,
> also there are limited (<=16) segments, so it won't take long to locate the 
> right area.
>
> Am I missing something?
>
> Regards,
> Xunlei
  if the crashkernel = auto is set in cmdline.  it represent crashk_res.end 
will exceed to 4G, the first allocate control pages will
  loop  million times. if we set crashk_res.end to the higher value manually,  
you can image

  Thanks
  zhongjiang
>>  if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT)
>>  break;
>>  /* See if I overlap any of the segments */
>
> .
>



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-08 Thread Xunlei Pang 
On 12/08/2016 at 10:37 AM, zhongjiang wrote:
> From: zhong jiang 
>
> A soft lookup will occur when I run trinity in syscall kexec_load.
> the corresponding stack information is as follows.
>
> [  237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
> [  237.242699] Kernel panic - not syncing: softlockup: hung tasks
> [  237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G   O L 
> V---   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
> [  237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 
> V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
> [  237.269752]  8187626b 18cfde31 88184c803e18 
> 81638f16
> [  237.277471]  88184c803e98 8163278f 0008 
> 88184c803ea8
> [  237.285190]  88184c803e48 18cfde31 88184c803e67 
> 
> [  237.292909] Call Trace:
> [  237.295404][] dump_stack+0x19/0x1b
> [  237.301352]  [] panic+0xd8/0x214
> [  237.306196]  [] watchdog_timer_fn+0x1cc/0x1e0
> [  237.312157]  [] ? watchdog_enable+0xc0/0xc0
> [  237.317955]  [] __hrtimer_run_queues+0xd2/0x260
> [  237.324087]  [] hrtimer_interrupt+0xb0/0x1e0
> [  237.329963]  [] ? call_softirq+0x1c/0x30
> [  237.335500]  [] local_apic_timer_interrupt+0x37/0x60
> [  237.342228]  [] smp_apic_timer_interrupt+0x3f/0x60
> [  237.348771]  [] apic_timer_interrupt+0x6d/0x80
> [  237.354967][] ? 
> kimage_alloc_control_pages+0x80/0x270
> [  237.362875]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
> [  237.369592]  [] ? do_kimage_alloc_init+0x1f/0x90
> [  237.375992]  [] kimage_alloc_init+0x12a/0x180
> [  237.382103]  [] SyS_kexec_load+0x20a/0x260
> [  237.387957]  [] system_call_fastpath+0x16/0x1b
>
> the first time allocate control pages may take too much time because
> crash_res.end can be set to a higher value. we need to add cond_resched
> to avoid the issue.
>
> The patch have been tested and above issue is not appear.
>
> Signed-off-by: zhong jiang 
> ---
>  kernel/kexec_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 5616755..bfc9621 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -441,6 +441,8 @@ static struct page 
> *kimage_alloc_crash_control_pages(struct kimage *image,
>   while (hole_end <= crashk_res.end) {
>   unsigned long i;
>  
> + cond_resched();
> +

I can't see why it would take a long time to loop inside, the job it does is 
simply to find a control area
not overlapped with image->segment[], you can see the loop "for (i = 0; i < 
image->nr_segments; i++)",
@hole_end will be advanced to the end of its next nearby segment once overlap 
was detected each loop,
also there are limited (<=16) segments, so it won't take long to locate the 
right area.

Am I missing something?

Regards,
Xunlei

>   if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT)
>   break;
>   /* See if I overlap any of the segments */


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-07 Thread Eric W. Biederman 
zhongjiang  writes:

> From: zhong jiang 
>
> A soft lookup will occur when I run trinity in syscall kexec_load.
> the corresponding stack information is as follows.

Acked-by: "Eric W. Biederman" 

>
> [  237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
> [  237.242699] Kernel panic - not syncing: softlockup: hung tasks
> [  237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G   O L 
> V---   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
> [  237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 
> V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
> [  237.269752]  8187626b 18cfde31 88184c803e18 
> 81638f16
> [  237.277471]  88184c803e98 8163278f 0008 
> 88184c803ea8
> [  237.285190]  88184c803e48 18cfde31 88184c803e67 
> 
> [  237.292909] Call Trace:
> [  237.295404][] dump_stack+0x19/0x1b
> [  237.301352]  [] panic+0xd8/0x214
> [  237.306196]  [] watchdog_timer_fn+0x1cc/0x1e0
> [  237.312157]  [] ? watchdog_enable+0xc0/0xc0
> [  237.317955]  [] __hrtimer_run_queues+0xd2/0x260
> [  237.324087]  [] hrtimer_interrupt+0xb0/0x1e0
> [  237.329963]  [] ? call_softirq+0x1c/0x30
> [  237.335500]  [] local_apic_timer_interrupt+0x37/0x60
> [  237.342228]  [] smp_apic_timer_interrupt+0x3f/0x60
> [  237.348771]  [] apic_timer_interrupt+0x6d/0x80
> [  237.354967][] ? 
> kimage_alloc_control_pages+0x80/0x270
> [  237.362875]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
> [  237.369592]  [] ? do_kimage_alloc_init+0x1f/0x90
> [  237.375992]  [] kimage_alloc_init+0x12a/0x180
> [  237.382103]  [] SyS_kexec_load+0x20a/0x260
> [  237.387957]  [] system_call_fastpath+0x16/0x1b
>
> the first time allocate control pages may take too much time because
> crash_res.end can be set to a higher value. we need to add cond_resched
> to avoid the issue.
>
> The patch have been tested and above issue is not appear.
>
> Signed-off-by: zhong jiang 
> ---
>  kernel/kexec_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 5616755..bfc9621 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -441,6 +441,8 @@ static struct page 
> *kimage_alloc_crash_control_pages(struct kimage *image,
>   while (hole_end <= crashk_res.end) {
>   unsigned long i;
>  
> + cond_resched();
> +
>   if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT)
>   break;
>   /* See if I overlap any of the segments */

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages

2016-12-07 Thread zhongjiang 
From: zhong jiang 

A soft lookup will occur when I run trinity in syscall kexec_load.
the corresponding stack information is as follows.

[  237.235937] BUG: soft lockup - CPU#6 stuck for 22s! [trinity-c6:13859]
[  237.242699] Kernel panic - not syncing: softlockup: hung tasks
[  237.248573] CPU: 6 PID: 13859 Comm: trinity-c6 Tainted: G   O L 
V---   3.10.0-327.28.3.35.zhongjiang.x86_64 #1
[  237.259984] Hardware name: Huawei Technologies Co., Ltd. Tecal BH622 
V2/BC01SRSA0, BIOS RMIBV386 06/30/2014
[  237.269752]  8187626b 18cfde31 88184c803e18 
81638f16
[  237.277471]  88184c803e98 8163278f 0008 
88184c803ea8
[  237.285190]  88184c803e48 18cfde31 88184c803e67 

[  237.292909] Call Trace:
[  237.295404][] dump_stack+0x19/0x1b
[  237.301352]  [] panic+0xd8/0x214
[  237.306196]  [] watchdog_timer_fn+0x1cc/0x1e0
[  237.312157]  [] ? watchdog_enable+0xc0/0xc0
[  237.317955]  [] __hrtimer_run_queues+0xd2/0x260
[  237.324087]  [] hrtimer_interrupt+0xb0/0x1e0
[  237.329963]  [] ? call_softirq+0x1c/0x30
[  237.335500]  [] local_apic_timer_interrupt+0x37/0x60
[  237.342228]  [] smp_apic_timer_interrupt+0x3f/0x60
[  237.348771]  [] apic_timer_interrupt+0x6d/0x80
[  237.354967][] ? 
kimage_alloc_control_pages+0x80/0x270
[  237.362875]  [] ? kmem_cache_alloc_trace+0x1ce/0x1f0
[  237.369592]  [] ? do_kimage_alloc_init+0x1f/0x90
[  237.375992]  [] kimage_alloc_init+0x12a/0x180
[  237.382103]  [] SyS_kexec_load+0x20a/0x260
[  237.387957]  [] system_call_fastpath+0x16/0x1b

the first time allocate control pages may take too much time because
crash_res.end can be set to a higher value. we need to add cond_resched
to avoid the issue.

The patch have been tested and above issue is not appear.

Signed-off-by: zhong jiang 
---
 kernel/kexec_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 5616755..bfc9621 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -441,6 +441,8 @@ static struct page *kimage_alloc_crash_control_pages(struct 
kimage *image,
while (hole_end <= crashk_res.end) {
unsigned long i;
 
+   cond_resched();
+
if (hole_end > KEXEC_CRASH_CONTROL_MEMORY_LIMIT)
break;
/* See if I overlap any of the segments */
-- 
1.8.3.1


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec