On Tue 24-07-18 14:22:06, Vlastimil Babka wrote: > On 07/24/2018 01:19 PM, Michal Hocko wrote: > >> When creating a crashdump, I definitely need the pages containing memmap > >> included in the dump, so I can inspect the struct pages. But this is a > >> bit recursive issue, so I'll try making it clearer: > >> > >> 1) there are kernel pages with data (e.g. slab) that I typically need in > >> the dump, and are not PageReserved > >> 2) there are struct pages for pages 1) in the memmap that physically > >> hold the pageflags for 1), and these are PageReserved > >> 3) there are struct pages for pages 2) somewhere else in the memmap, > >> physically hold the pageflags for 2). They are probably also > >> PageReserved themselves ? and self-referencing. > >> > >> Excluding PageReserved from dump means there won't be cases 2) and 3) in > >> the dump, which at least for case 2) is making such dump almost useless > >> in many cases. > > > > Yes, we cannot simply exclude all PageReserved pages. I was merely > > suggesting to rule out new special PageReserved pages that are denoting > > offline pages. The same could be applied to HWPoison pages > > So how about marking them with some "page type" that we got after > Matthew's struct page reorg? I assume the pages we're talking about are > in a state that they don't need the mapcount/mapping field or whatever > unions with the page type... but I guess some care would be needed to > not have false positives when the union field is actually used but > happens to look like the new type. The idea was to use PageReserved because those pages are generally ignored by MM and then reuse some parts of the struct page. It belongs to the owner of the page and nothing should be really used from it at the time when you mark it offline. So pagetype or something else is merely an implementation detail. -- Michal Hocko SUSE Labs
