On 04/27/2017 at 01:44 PM, Dave Young wrote:
> Hi Xunlei,
>
> On 04/27/17 at 01:25pm, Xunlei Pang wrote:
>> On 04/27/2017 at 11:06 AM, Dave Young wrote:
>>> [snip]
>>>>>>>
>>>>>>> static int __init crash_save_vmcoreinfo_init(void)
>>>>>>> {
>>>>>>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */
>>>>>> Can we add a comment in the VMCOREINFO_BYTES header file about the one
>>>>>> page assumption?
>>>>>>
>>>>>> Or just define the VMCOREINFO_BYTES as PAGE_SIZE instead of 4096
>>>>> Yes, I considered this before, but VMCOREINFO_BYTES is also used by VMCOREINFO_NOTE_SIZE
>>>>> definition which is exported to sysfs, also some platform has larger page size(64KB), so
>>>>> I didn't touch this 4096 value.
>>>>>
>>>>> I think I should use kmalloc() to allocate both of them, then move this comment to Patch3
>>>>> kimage_crash_copy_vmcoreinfo().
>>>> But on the other hand, using a separate page for them seems safer compared with
>>>> using frequently-used slab, what's your opinion?
>>> I feel current page based way is better.
>>>
>>> For 64k page the vmcore note size will increase it seems fine. Do you
>>> have concern in mind?
>> Since tools are supposed to acquire vmcoreinfo note size from sysfs, it should be safe to do so,
>> except that there is some waste in memory for larger PAGE_SIZE.
> Either way is fine to me, I think it is up to your implementation, if
> choose page alloc then modify the macro with PAGE_SIZE looks better.
OK, I will use PAGE_SIZE then, thanks for your comments.
>
> Thanks
> Dave
>
> _______________________________________________
> kexec mailing list
> kexec@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
