linux-kernel - Re: [Patch 0/5] I/O statistics through request queues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <y0mvem8thc3.fsf@ton.toronto.redhat.com>
Date:	25 Oct 2006 13:50:52 -0400
From:	fche@...hat.com (Frank Ch. Eigler)
To:	Martin Peschke <mp3@...ibm.com>
Cc:	Phillip Susi <psusi@....rr.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [Patch 0/5] I/O statistics through request queues


Martin Peschke <mp3@...ibm.com> writes:

> [...]  The tricky question is: is event processing, that is,
> statistics data aggregation, better done later (in user space), or
> immediately (in the kernel). Both approaches exist: blktrace/btt vs.
> gendisk statistics used by iostat, for example. [...]

I would put it one step farther: the tricky question is whether it's
worth separating marking the state change events ("request X
enqueued") from the action to be taken ("track statistics", "collect
trace records").

The reason I brought up the lttng/marker thread here was because that
suggests a way of addressing several of the problems at the same time.
This could work thusly: (This will sound familiar to OLS attendees.)

- The blktrace code would adopt a generic marker mechanism such as
  that (still) evolving within the lttng/systemtap effort.  These
  markers would replace calls to inline functions such as
      blk_add_trace_bio(q,bio,BLK_TA_QUEUE);
  with something like
      MARK(blk_bio_queue,q,bio);

- The blktrace code that formats and manages trace data would become a
  consumer of the marker API.  It would be hooked up at runtime to
  these markers.  When the events fire, the tracing backend receiving
  the callbacks could do the same thing it does now.  (With the
  markers dormant, the cost should not be much higher than the current
  (likely (!q->blk_trace)) conditional.)

- The mp3 statistics code would be an alternate backend to these same
  markers.  It could be activated or deactivated on the fly (to let
  another subsystem use the markers).  The code would maintain statistics
  in its own memory and could present the data on /proc or whatnot, the
  same way as today.

- Additional backends would be immediately possible: lttng style
  tracing or even fully programmable systemtap probing / analysis
  could all be dynamically activated without further kernel patches or
  rebooting.

>From a user's point of view, it could be the best of all worlds: easy
to get a complete trace for detailed analysis, easy to retain plain
statistics for simple monitoring, easy to do something more elaborate
if necessary.

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