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

[Srikar Dronamraju]

> > Current slot allocation mechanism:
> > 1. Allocate one dedicated slot per user breakpoint. Each slot is big
> > enuf to accomodate the biggest instruction for that architecture. (16
> > bytes for x86).
> > 2. We currently allocate only one page for slots. Hence the number of
> > slots is limited to active breakpoint hits on that process.
> > 3. Bitmap to track used slots. 
> 
> 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.
> 

Certainly doable but it has its share of drawbacks.
1. On every probe hit we have to copy the instruction into the
slot, so there is a performance penalty. 

2  This might complicate booster probe, because the jump
instruction that follows the original instruction now actually have to
coded every time.

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.

4. I dont see a need for clearing slots after post processing, but if
we need to clear we then are adding more penalties because not only are
we clearing the slots but the post processing then cant happen in
interrupt context.

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.).

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.

--
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/