Summary: | uprobes: smarter insn slot allocation for SSOL | ||
---|---|---|---|
Product: | systemtap | Reporter: | Jim Keniston <jkenisto> |
Component: | uprobes | Assignee: | Unassigned <systemtap> |
Status: | RESOLVED WONTFIX | ||
Severity: | minor | CC: | fche |
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Jim Keniston
2007-11-06 00:47:07 UTC
Would it make sense to bypass uprobe_ssol_slot() totally for powerpc (and like archs) that may potentially never need the lru to kick in? (In reply to comment #1) > Would it make sense to bypass uprobe_ssol_slot() totally for powerpc (and like > archs) that may potentially never need the lru to kick in? There's definitely sense in that. It would impose a theoretical limit on the number of probepoints a process could hit; but registering 16K uprobes would probably stretch some practical limits -- e.g., related to the size of struct uprobe_probept or the lengths of the hash lists in uproc->uprobe_table[]. Unfortunately, making all the slots private on 1-2 architectures doesn't reduce overall code complexity. Anything like this is unlikely to be changed in stap classic uprobes; and as to lkml-track uprobes, that's an issue to raise there. |