From: zhong jiang <zhongjiang@huawei.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Xunlei Pang <xpang@redhat.com>,
akpm@linux-foundation.org, xlpang@redhat.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages
Date: Fri, 9 Dec 2016 13:56:50 +0800 [thread overview]
Message-ID: <584A47A2.1040001@huawei.com> (raw)
In-Reply-To: <87inqtn0gm.fsf@xmission.com>
On 2016/12/9 13:19, Eric W. Biederman wrote:
> zhong jiang <zhongjiang@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@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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: zhong jiang <zhongjiang@huawei.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: <xlpang@redhat.com>, Xunlei Pang <xpang@redhat.com>,
<akpm@linux-foundation.org>, <kexec@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages
Date: Fri, 9 Dec 2016 13:56:50 +0800 [thread overview]
Message-ID: <584A47A2.1040001@huawei.com> (raw)
In-Reply-To: <87inqtn0gm.fsf@xmission.com>
On 2016/12/9 13:19, Eric W. Biederman wrote:
> zhong jiang <zhongjiang@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@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
next prev parent reply other threads:[~2016-12-09 5:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 2:37 [PATCH v2] kexec: add cond_resched into kimage_alloc_crash_control_pages zhongjiang
2016-12-08 2:37 ` zhongjiang
2016-12-08 3:22 ` Eric W. Biederman
2016-12-08 3:22 ` Eric W. Biederman
2016-12-08 9:41 ` Xunlei Pang
2016-12-08 9:41 ` Xunlei Pang
2016-12-09 5:13 ` zhong jiang
2016-12-09 5:13 ` zhong jiang
2016-12-09 5:19 ` Eric W. Biederman
2016-12-09 5:19 ` Eric W. Biederman
2016-12-09 5:56 ` zhong jiang [this message]
2016-12-09 5:56 ` zhong jiang
2016-12-09 7:16 ` Xunlei Pang
2016-12-09 7:16 ` Xunlei Pang
2016-12-19 3:23 ` Baoquan He
2016-12-19 3:23 ` Baoquan He
2016-12-21 5:06 ` Xunlei Pang
2016-12-21 5:06 ` Xunlei Pang
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=584A47A2.1040001@huawei.com \
--to=zhongjiang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xlpang@redhat.com \
--cc=xpang@redhat.com \
/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.