Bug 11671

Summary:	Allocate __stp_tf_vma_entry dynamically
Product:	systemtap	Reporter:	Mark Wielaard <mark>
Component:	runtime	Assignee:	Unassigned <systemtap>
Status:	RESOLVED FIXED
Severity:	normal	CC:	jan
Priority:	P2
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Mark Wielaard 2010-06-07 11:36:40 UTC

Currently the __stp_tf_vma_free_list_items array list is allocated staticly with
the value of TASK_FINDER_VMA_ENTRY_ITEMS in runtime/task_finder_vma.c.

Setting this to some arbitrary default is not very efficient, since this is
often way too much for tracking a single process, but often too little when
tracking the whole system.

It would be good if new list items could be allocated (and deallocated?)
dynamically. In theory this should be possible since the table should only be
updated with new items from a safe context (but can be read/searched from any
context).

Comment 1 Mark Wielaard 2011-12-09 15:08:14 UTC

commit c2537ee6d68b2358e8f74cc5413772915e5742d6
Author: Mark Wielaard <mjw@redhat.com>
Date:   Fri Dec 9 10:46:20 2011 +0100

    PR11671 Allocate __stp_tf_vma_entry dynamically.
    
    Get rid of TASK_FINDER_VMA_ENTRY_ITEMS and __stp_tf_vma_free_list_items
    array list completely. All __stp_tf_vma_entry are allocated dynamically
    now. This is possible since stap_add_vma_map_info() is only called
    through the task_finder from a user context.
    
    There is no more fixed maximum number of VMA pages that will be tracked
    at runtime. This reduces memory use for those scripts that don't need any,
    or only limited target process VMA tracking and allows easier system
    wide probes inspecting shared library variables and/or user backtraces.
    stap will now silently ignore -DTASK_FINDER_VMA_ENTRY_ITEMS.

Plus some follow up commits to fix some corner cases (3dde67, 972ea1 and 7fbefb)