On 09/03/2013 07:19 PM, Christopher Covington wrote: >>> My current prototype adds a new command to criu: "sample", requiring an >>> intervals argument and a workload to execute. When given this command, criu >>> fork's a child process which opens a perf event that is set up to signal the >>> parent criu process when the first interval has elapsed (I'm measuring >>> instructions, but it could be any perf event). >> >> I'm not familiar with internals of perf, can you shed more light on this, >> please. >> What does "opens a perf event" occurs? Is it an eventfd descriptor with >> respective >> setup or something else? > > http://web.eece.maine.edu/~vweaver/projects/perf_events/perf_event_open.html > > I'm passing initial settings as an argument to the perf event open system > call, which returns a file descriptor. With the file descriptor in hand I can > then use fcntl and ioctl to do the last part of the setup like setting the > asynchronous flag and making the parent process the owner so that it gets the > wakeup signal.
Why do you configure signal delivery for event notification? Isn't it more convenient just to poll() the perf event descriptor? I'm reading the kernel's sys_perf_event_open() stuff and see that it's perfectly poll-able. >>> What do people think of this approach? Would it make more sense to add >>> something that depends on CRIU to perf tools? Should I look more closely at >>> a >>> library-based approach? Could potential library users make use of this sort >>> of >>> fork+exec+signal approach instead of making function calls? >> >> For me the scenario you proposes fits naturally into the "service" thing >> being >> developed. The part that is missing for your case is that for now "service" >> is >> supposed to serve only one "dump-me" request per-connection. >> >> Can we somehow from one process configure perf events to come to another >> process? >> If yes, then we can make your case look like >> >> 1. criu service starts >> 2. a process with your workload starts and >> a) opens perf event >> b) connects to criu service >> c) delegates the perf event to service >> d) sends the "dump me request", with "use delegated event" flag set >> 3. your workload starts >> >> After this once perf event occurs, it's caught by criu service, which in turn >> dumps the process. >> >> So is it possible to make this "perf event delegation to other process"? > > There are two things to be delegated. The first is who gets the wakeup signal. > As long as the process identifier for the service is known, it should be > trivial to make a file control ownership call on the perf event file > descriptor before the workload is executed. The other resource is the file > descriptor itself, which one must re-program and reset to capture multiple > checkpoints. The service should have access to the file descriptor once the > first dump is taken, which is the earliest it would need to perform any > operations on it anyhow. Ah, I see. Well, this fits fine into existing service API -- the "dump-me" requester would have to pass and fd with a directory where to put image files to, so we can just extend one and pass the fd with events. > I think this still leaves the specifics of multiple checkpoint dumps in > sequence somewhat unresolved. The service is going to look like a "classical" server -- it listens for connection, then spawns a child and lets one handle the request. After doing so it's ready to listen for more requests. > I think I'll try to switch over to the service workflow and play around with > it a little to get a better idea of what the options might be. That's great! Thanks, Pavel -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
