On Fri, 1 Sep 2017 10:16:21 +0200 Vlastimil Babka <[email protected]> wrote: > > Right, but that should work with the latest trace-cmd. Does it? > > Hmm, by "sparse memory model without vmemmap" I don't mean there's a > number instead of "vmemmap_base". I mean CONFIG_SPARSEMEM=y > > Then __pfn_to_page() looks like this: > > #define __page_to_pfn(pg) \ > ({ const struct page *__pg = (pg); \ > int __sec = page_to_section(__pg); \ > (unsigned long)(__pg - > __section_mem_map_addr(__nr_to_section(__sec))); \ > }) > > Then the part of format file looks like this: > > REC->pfn != -1UL ? ({ unsigned long __pfn = (REC->pfn); struct mem_section > *__sec = __pfn_to_section(__pfn); __section_mem_map_addr(__sec) + __pfn; }) : > ((void *)0)
Ouch. > > The section things involve some array lookups, so I don't see how we > could pass it to tracing userspace. Would we want to special-case > this config to store both pfn and struct page in the trace frame? And > make sure the simpler ones work despite all the exsisting gotchas? > I'd rather say we should either store both pfn and page pointer, or > just throw away the page pointer as the pfn is enough to e.g. match > alloc and free, and also much more deterministic. Write up a patch and we'll take a look. -- Steve
