Thank you Kazuhito san. I will check the mentioned source. Manty On Wed, Jul 28, 2021 at 2:43 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx> wrote: > > -----Original Message----- > > Hi kazuhito san, > > > > Just following up on my last email. > > Sincere apologies for asking for your time. > > I want to specifically understand what the "user data" section is and > > what it means to exclude it from the dump. > > "user data" are anonymous pages or huge pages. > https://github.com/makedumpfile/makedumpfile/blob/master/makedumpfile.c#L6224 > > Please consult the __exclude_unnecessary_pages() function above for > what conditions correspond to the type of page. > > Thanks, > Kazu > > > > > Thank you very much. > > > > Best Regards, > > Manty > > > > On Fri, Jul 9, 2021 at 10:45 AM manty kuma <mantykuma@xxxxxxxxx> wrote: > > > > > > Hi Kazuhito san, > > > > > > I am looking to better understand the sections being filtering out > > > with each of the following options. > > > > > > Zero page: > > > Pages that are empty. Ignoring these pages won't have any impact on analysis. > > > > > > non-private cache and private cache: > > > What exactly are these sections of memory? Just a one-line overview > > > about them is sufficient. > > > (My understanding was that cache is not part of RAM. Is this cache > > > something else? Like some bookkeeping data maintained by the kernel?) > > > > > > > > > user data: > > > Are these sections of the memory for the user space processes/memory > > > sections allocated using malloc? > > > My understanding is that If I exclude this section, gcore would not > > > work. Is my understanding correct? > > > I expected this section to be big. But in fact excluding this did not > > > have much impact on the dump size. > > > > > > free page: > > > unallocated pages. Since they are not allocated. filtering them out > > > won't have any impact on dump analysis. > > > Please correct me if I am wrong. > > > > > > > > > If there is already some place that explains what these sections > > > filter out, please just drop the reference to them and i will look > > > into it. > > > Thank you very much in advance! > > > > > > Manty > > > > > > On Thu, Jul 8, 2021 at 8:17 PM manty kuma <mantykuma@xxxxxxxxx> wrote: > > > > > > > > Sorry. I am not sure how but I completely missed this email. > > > > Yes, /tmp was not available in my env. I just did mkdir before > > > > executing `makedumpfile` and it is now working well. > > > > Thank you very much. > > > > > > > > On Mon, Jun 28, 2021 at 4:07 PM HAGIO KAZUHITO(萩尾 一仁) > > > > <k-hagio-ab@xxxxxxx> wrote: > > > > > > > > > > -----Original Message----- > > > > > > Hi Kazuhito san, > > > > > > > > > > > > I am getting the following error when trying to use makedumpfile utility. > > > > > > > > > > > > > copy_vmcoreinfo: Can't open the vmcoreinfo file(/tmp/vmcoreinfoLUQc25). No such file or directory. > > > > > > > makedumpfile Failed > > > > > > > > > > > > In your setup how are you providing the vmcoreinfo file? In my case it > > > > > > is checking /tmp/vmcoreinfoLUQc25 > > > > > > Who generates this file? > > > > > > > > > > Generally, vmcoreinfo is copied from vmcore's ELF note to /tmp/vmcoreinfoXXXXXX > > > > > by makedumpfile, please see copy_vmcoreinfo(). So no need to provide explicitly. > > > > > > > > > > Is there the /tmp directory on your environment? > > > > > > > > > > Kazu > > > > > > > > > > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
