Hi Catalin, From: ext Catalin Marinas <catalin.mari...@arm.com> Subject: Re: [RFC][PATCH 0/1] kmemleak: Fix false positive with alias Date: Fri, 17 Sep 2010 18:18:47 +0200
> On Tue, 2010-08-10 at 18:49 +0300, Hiroshi DOYU wrote: >> Now there's not much difference with the attached patch, a new version >> of alias. >> >> / # modprobe kmemleak-special-test use_alias=0 >> / # time echo scan > /sys/kernel/debug/kmemleak >> real 0m 2.30s >> user 0m 0.00s >> sys 0m 2.30s >> >> / # modprobe kmemleak-special-test use_alias=1 >> / # time echo scan > /sys/kernel/debug/kmemleak >> real 0m 3.91s >> user 0m 0.00s >> sys 0m 3.91s > > So to understand - the first case is memory scanning without any aliases > configured. The second case is the alias scanning using a separate > prio_tree. The impact seems to be quite big. > > But I wouldn't complicate the code with the callback mechanism, > especially when loadable modules are considered. Is the pointer > conversion always linear? Maybe we can just add an offset to the > scan_area structure that is used for conversion rather than a callback. > > Another advantage of the linear offset would be that we can avoid the > call for removing the conversion. > > Is this feasible for your needs? The formula is: new_value = virt_to_phys(original address) | each attributes; Attribute bits must be ingored. So the conversion is: new_value &= ~each attributes; original address = phys_to_virt(new_value); Could adding an offset to the scan_area solve this case? > No point really in making it too > generic if the simple offset would (hopefully) do. I guess other iommu pagetable may be same? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
