On 7/7/15 10:27 AM, Andy Lutomirski wrote:
On Tue, Jul 7, 2015 at 9:25 AM, Arnaldo Carvalho de Melo
<acme@xxxxxxxxxx> wrote:
Em Tue, Jul 07, 2015 at 06:43:46PM +0300, Andrew Vagin escreveu:
On Mon, Jul 06, 2015 at 10:10:32AM -0700, Andy Lutomirski wrote:
On Mon, Jul 6, 2015 at 1:47 AM, Andrey Vagin <avagin@xxxxxxxxxx> wrote:
Would it make more sense to have a new syscall instead? You could
even still use nlattr formatting for the syscall results.
Andy, thank you for the feedback. I got your points. I need time to
think about them. I suppose that a new syscall can be more suitable in
this case, and I need time to form a vision of it. If you have any ideas
or thoughts, I would be glad to know about them.
If a new syscall would indeed be better for this, then using
sys_perf_event_open and on one of the perf_event_attr flip a bit to ask
for those PERF_RECORD_{COMM,FORK,PERF_RECORD_MMAP2, etc} to be generated
in the perf buffer could make it reuse all the userspace tooling, with
really minimal change: flip the bit, don't synthesize it from /proc.
Hmm, that's an interesting thought.
Andrew, would that work for you?
It's an interesting option to look at. It provides a fixed sized ring
buffer. The dummy event can be used as the event to trigger the
generation of task data. The LOST event can tell you if the buffer is
too small.
Of course the devil is in the details. The buffer for event tasks will
need to be fairly large. That size is only needed for the initial task
data meaning the global mmap size is not right for it and this
particular buffer can be reduced after startup.
The initial task detection can generate a flood of data in a very short
amount of time since kernel side is in a tight loop walking tasks and
maps and there is nothing to throttle it beyond the buffer filling --
and that just means lost data -- and an occasional need_resched check.
Perhaps the kernel loop will need to pause if the buffer is full to give
userspace a moment to collect data rather than just dropping it.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
