Re: [PATCH] some optimizations for Virtual Machines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Thanks very much for your interest in utrace!  

> 1- Order of callbacks

This subject is on the TODO list, part of "Engine interaction issues".
You are not the first to bring it up.  I'd like to discuss the question
more broadly before considering a particular change to the behavior.
I'll do this in a separate thread.  I'd also encourage you to write up
thoughts about things like this on the wiki (make new pages under, if you are so inclined.

> 2- Access to traced process vm.

I didn't include any interfaces for this in the utrace core, because
there isn't really any need.  That is, there is no direct interaction
with utrace internals required.  Some utrace-using kernel code can just
do the memory access itself, perhaps after using utrace to get threads
quiescent (and call writeback, for ia64).  You can use access_process_vm,
or do something in more specific code that does what it does, i.e. use
get_user_pages.  In recent versions, access_process_vm is no longer
exported to modules (though maybe it will be again).  But get_user_pages
is, and access_process_vm is a pretty simple function anyway.

I'm not at all against some new, convenient, exported calls for doing
this.  But they do not need to be part of the utrace core.  I think you
should just use whatever is convenient to use in your own code now.  When
there are a few different things satisfying their own very similar needs
like this, then something will gel for new shared interfaces to use.

> 3- In the patch I have also implemented the support for PTRACE_MULTI 

Personally, I am not interested in additions to the ptrace interface at
all.  I don't intend to talk you out of doing it.  I completely
sympathize with your approach of adding what you most need to the
facility that is already working now, and we do not yet have any nice
post-ptrace user-level interface in production.  I just don't care to
comment on the details and merits of any new ptrace requests.  
What I am very interested in are two things about your work.

First, what issues come up with the utrace/tracehook calls in detail in
your work?  (This being things aside from the engine interaction question.)
In particular, tracehook_syscall_* come to mind.  Are those doing what
you need?

Second, what needs/desires/bottlenecks in a higher-level tracing
interface do you think are particular to the VM implementation case?
Doing more operations with fewer context switches is a universal and
well-known need, that anyone designing a new interface is well aware of.
If there are unusual needs or usage patterns peculiar to your kind of
use, I'd like to get more details about those into discussion.  Doing
tracehook_abort_syscall and fetching those details from the registers
portably is the only thing I think of off hand.  For some x86 stuff,
maybe there is segmentation magic to be done too?

In future, I think it would be most useful if you publish your changes as
a series of separate patches (a la quilt).  If you make a utrace core
change, put that in a separate patch.  If you add some utility function,
separate the patch for that.  Put your ptrace additions in a patch that's
just about that.  Then it's easier to review each piece of the puzzle on
its own merits.


[Index of Archives]     [Kernel Discussion]     [Gimp]     [Yosemite News]

  Powered by Linux