On 2016/12/9 13:19, Eric W. Biederman wrote: > zhong jiang <zhongjiang at huawei.com> writes: > >> On 2016/12/8 17:41, Xunlei Pang wrote: >>> On 12/08/2016 at 10:37 AM, zhongjiang wrote: >>>> From: zhong jiang <zhongjiang at huawei.com> >>>> > [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