[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53F4B887.7060701@sr71.net>
Date: Wed, 20 Aug 2014 08:02:31 -0700
From: Dave Hansen <dave@...1.net>
To: Ingo Molnar <mingo@...nel.org>
CC: linux-kernel@...r.kernel.org, dave.hansen@...ux.intel.com,
peterz@...radead.org, mingo@...hat.com, ak@...ux.intel.com,
tim.c.chen@...ux.intel.com, akpm@...ux-foundation.org,
cl@...ux.com, penberg@...nel.org, linux-mm@...ck.org,
kirill@...temov.name, lauraa@...eaurora.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] [v2] TAINT_PERFORMANCE
On 08/20/2014 01:11 AM, Ingo Molnar wrote:
> In any case I don't think it's a good idea to abuse existing
> facilities just to gain attention: you'll get the extra
> attention, but the abuse dilutes the utility of those only
> tangentially related facilities.
I'm happy to rip the TAINT parts out. I was just hoping that some
tooling might pick up the taint flags today, and this could get picked
up without modification of whatever those tools are.
I was _really_ hoping the dmesg from the taint would be ugly and loud
enough to be sufficient, but it was relatively terse.
> A better option might be to declare known performance killers
> in /proc/config_debug or so, and maybe print them once at the
> end of the bootup, with a 'WARNING:' or 'INFO:' prefix. That
> way tooling (benchmarks, profilers, etc.) can print them, but
> it's also present in the syslog, just in case.
Sounds reasonable to me. As long as we have _something_ that shows up
in dmesg, it will help.
--
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