https://bugs.kde.org/show_bug.cgi?id=514297
--- Comment #21 from Philippe Waroquiers <[email protected]> --- (In reply to mcermak from comment #18) > I've used the following systemtap script to monitor the madvise syscall > system-wide: > > # stap -ve 'probe syscall.madvise {printdln(" ", advice_str, execname())}' > > Apparently, a guard page installation is rare. One can trigger it with e.g. > `yum makecache`, some curl invocations or when cloning the valgrind sources > with git. But typically just once per process lifetime. I guess you do not observe it very often possibly because most of the processes do not use threads (and so, do not need to install such a guard page). Applications that use a thread are (I believe) by default adding such a guard page. > > You are right that is_valid_for() may become expensive with my patch, but > only where nsegments[i].hasGuardPages is True. Having said all that, in > practice such condition is met with just a very few segments - typically > zero or one in practice. So I'm not overly worried about it. I might > easily be mistaken though. Please let me know if you disagree. The problem that I see is that even if it is only for a few segments, for this segment, is_valid_for will become (very?) expensive. For example, the leak search calls is_valid_for for all ptr aligned 8 bytes in the reachable memory. I suspect that this might give significant perf impact (for multi threads applications for which we do many leak search, typical case at my day job). Note that significant effort was spent to make is_valid_for fast. For example, segments are maintained in an array allowing dichotomic search but even with that, a "fast" cache was put in front of this dichotomic search. So, this seems to be highly performance critical. So, ideally, checking for guard page should be fast either as suggested by Mark using a specific data structure associated to the segment containing guard pages (e.g. a sorted array of guard page in which a dichotomic search can be used) or alternatively make a new "guard page" segment kind. (the advantage of this last approach is that we know that the perf will be similar to what is done on kernels not using such MADVISE as today each guard page is a segment. And so the fast cache + dichotomic search can be used. Another advantage of this approach is that guard pages will be visible in the valgrind data structure/aspacemgr debug or information report code. But adding a new segment kind might have more impact. In both cases, it is needed to track creation or destruction of guard pages to maintain the data structure in sync with the kernel view. Thanks Philippe -- You are receiving this mail because: You are watching all bug changes.
