linux-kernel - Re: [PATCH 2/2] blktrace: fix output of BLK_TC

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: <20090401125205.GD25493@ghostprotocols.net>
Date:	Wed, 1 Apr 2009 09:52:05 -0300
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Li Zefan <lizf@...fujitsu.com>, Jens Axboe <jens.axboe@...cle.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] blktrace: fix output of BLK_TC_PC events

Em Wed, Apr 01, 2009 at 01:00:16PM +0200, Ingo Molnar escreveu:
> 
> * Li Zefan <lizf@...fujitsu.com> wrote:
> 
> > +	} else {
> > +		if (t_sec(ent))
> > +			return trace_seq_printf(s, "%llu + %u [%d]\n",
> > +						t_sector(ent),
> > +						t_sec(ent), t_error(ent));
> > +		return trace_seq_printf(s, "%llu [%d]\n",
> > +					t_sector(ent), t_error(ent));
> > +	}
> >  }
> >  
> >  static int blk_log_remap(struct trace_seq *s, const struct trace_entry *ent)
> 
> Neat shortcut - packet command requests can be quite large in 
> special cases, right?
> 
> Sidenote. Right now we reserve the full packet length in the trace 
> buffer, then copy the full packet into the trace buffer:
> 
>                 if (pdu_len)
>                         memcpy((void *) t + sizeof(*t), pdu_data, pdu_len);
> 
> ... just to scan it a second time during output and discard much of 
> it later on if it has a lot of trailing zeroes.
> 
> It might make sense to pre-compress: by extending the trace record 
> format with a trailing-zeroes field.

You mean something like asking, at tracer registration time to do this
kind of compression and have it done on the core tracing code? Looks
worthy if we can find a second tracer that would benefit from the space
savings at the cost of using more CPU at each event.

But perhaps providing a "memcpy" replacement to be used in such things
and leaving this to the user to decide, i.e. it may be interesting in
certain scenarios to be able to do:

echo 1 > /sys/kernel/debug/tracing/options/compress

And have the payload compressed.
 
> But that would make it more complex and key to tracers is simplicity 
> of data acquisition.
> 
> Dunno, probably not worth it, except if data stream bloat becomes a 
> real issue (which i'd not expect them to become in this case).
> 
> Anyway - Jens, the two patches look good to me, do they look fine to 
> you too?

To me too,

Acked-by: Arnaldo Carvalho de Melo <acme@...hat.com>

to this one too.

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