[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <l2xaa79d98a1005101457n3526dafag13ea897000c8066b@mail.gmail.com>
Date: Tue, 11 May 2010 01:57:14 +0400
From: Cyrill Gorcunov <gorcunov@...il.com>
To: "rostedt@...dmis.org" <rostedt@...dmis.org>
Cc: Lin Ming <ming.m.lin@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [rfc] x86,perf: P4 PMU -- use hash for p4_get_escr_idx
On Tuesday, May 11, 2010, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Mon, 2010-05-10 at 19:27 +0400, Cyrill Gorcunov wrote:
>
>> static int p4_get_escr_idx(unsigned int addr)
>> {
>> - unsigned int i;
>> + unsigned int idx = P4_ESCR_MSR_IDX(addr);
>>
>> - for (i = 0; i < ARRAY_SIZE(p4_escr_map); i++) {
>> - if (addr == p4_escr_map[i])
>> - return i;
>> - }
>> + BUG_ON(idx >= P4_ESCR_MSR_TABLE_SIZE);
>> + BUG_ON(!p4_escr_table[idx]);
>
> Is there any softer way to handle this. IOW, must it be a BUG_ON()? or
> can you add a WARN_ON() and pass back something that will cause it to
> fail a bit nicer.
>
yes, we could warn here and just drop such an event from scheduling.
Thanks Steven! Dont know why i didnt use it initially ;)
> A BUG_ON() may panic the box and if you are in X on a laptop, all you
> see is that your box locked up hard. If this is a WARN_ON() and you can
> prevent further damage to the computer (no file corruption or anything)
> then the user may notice, "Oh, my dmesg has this nasty error here", and
> report something useful.
>
> You could do:
>
> if (WARN_ON(idx >= P4_ESCR_MSR_TABLE_SIZE))
> return -1;
>
> or whatever.
>
> Thanks,
>
> -- Steve
>
>>
>> - return -1;
>> + return idx;
>> }
>>
>
>
--
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/
Powered by blists - more mailing lists