linux-kernel - Re: [PATCH 15/34] perf, core: Add a concept of a weightened sample

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: <1350998032.13456.25.camel@twins>
Date:	Tue, 23 Oct 2012 15:13:52 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org, acme@...hat.com,
	eranian@...gle.com, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 15/34] perf, core: Add a concept of a weightened sample

On Thu, 2012-10-18 at 16:19 -0700, Andi Kleen wrote:
> @@ -601,6 +602,7 @@ static inline void perf_sample_data_init(struct perf_sample_data *data,
>         data->regs_user.abi = PERF_SAMPLE_REGS_ABI_NONE;
>         data->regs_user.regs = NULL;
>         data->stack_user_size = 0;
> +       data->weight = 0;
>  }
>  
>  extern void perf_output_sample(struct perf_output_handle *handle,

> @@ -562,6 +565,7 @@ enum perf_event_type {
>          *      { u64                   stream_id;} && PERF_SAMPLE_STREAM_ID
>          *      { u32                   cpu, res; } && PERF_SAMPLE_CPU
>          *      { u64                   period;   } && PERF_SAMPLE_PERIOD
> +        *      { u64                   weight;   } && PERF_SAMPLE_WEIGHT
>          *
>          *      { struct read_format    values;   } && PERF_SAMPLE_READ
>          * 

So the only issues I have are that his makes every sample more expensive
by having to 0 out that weight data and the sample placement.

I don't think avoiding that weight init is really worth the pain that'll
cause, so we'll just leave it there.

As to the placement, I suppose it makes sense, although Stephane once
complained about these fields not being in PERF_SAMPLE numeric order.
Since we're not that anyway, he'll have to deal with it.. Stephane, any
strong arguments against this placement?

Also, Stephane, you said you had something similar in you LL patches, do
you mean to re-use this or should we re-base this on top of your
patches.. ?
--
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/