Re: [rfc] x86,perf: P4 PMU -- use hash for p4_get_escr_idx

[Cyrill Gorcunov]

On Tuesday, May 11, 2010, Steven Rostedt <rostedt@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/