Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot allocationfor Execution out of line(XOL)

[Srikar Dronamraju]

> > > An alternative method would be to have 1 slot per cpu, and manage the
> > > slot content using preemption notifiers. That gives you a fixed number
> > > of slots and an unlimited number of probe points.
> > > 
> > > If the preemption happens to be a migration you need to rewrite the
> > > userspace IP to point to the new slot -- if indeed the task was inside
> > > one when it got preempted -- but that all should be doable.
> > > 
> > 
> > 3. Yes migration is an issue esp
> > -  if a thread of the same process that hit a breakpoint is scheduled into the same cpu and that newly scheduled thread hits a breakpoint. 
> > - Something similar can happen if a multithreaded process runs on a
> >   uniprocessor machine.
> 
> > 5. I think we are covered on the cpu hotplug too, (i.e not sure if we have
> > to make uprobes cpu hot plug aware.).
> 
> Not if you use a slot per cpu and use preemption notifiers, the
> preemption notifiers will migrate the slots around.


Lets say the thread while singlestepping the process gets
pre-empted. Eventually the cpu might run some other thread of the same
process before picking the first run thread. Or the first run
thread could after migration due to load balancing or whatever end up
running on  a different thread?  How do we handle these cases? 

> 
> > 6. We would still be allocating a page for the slots. Unless we want
> > to expand to more slots than available in one page, I dont see the
> > disadvantages with the current approach.
> 
> The current approach limits the number of probes to what fits in a page.
> The slot per cpu approach will have no such limit.


yes the limit on number of probes is a limitation. For now the
implementation would be straight and easy. We could either rework on the
algorithm or add more pages depending on how often uprobes gets used.

> > 2  This might complicate booster probe, because the jump
> > instruction that follows the original instruction now actually have to
> > coded every time.
> 
> Why can't you keep the whole replacement sequence in-tact? Simply copy
> it out into the slot each time.

Yes, if we use jump absolute then the replacement sequence stays
in-tact.

--
Thanks and Regards
Srikar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/