Jeremy Fitzhardinge wrote:
Yeah, that seems reasonable if you're optimising for overall size. Did
you count the difference of including the function name? We decided not
to include it for BUG because its usefulness/size tradeoff didn't seem
terribly important.
in the WARN_ON case it's not th
Arjan van de Ven wrote:
> Jeremy Fitzhardinge wrote:
>> Arjan van de Ven wrote:
>>> This patch moves WARN_ON() out of line entirely. I've considered
>>> keeping
>>> the test inline and moving only the slowpath out of line, but I decided
>>> against that: an out of line test reduces the pressure on
Arjan van de Ven wrote:
So... call me unconvinced for now. There's 30 Kb on the table with the
easy, obviously safe
transform, and maybe another 1Kb with the much more tricky trapping
scenario, but only
for the vmlinux case; the module case seems to be a loss instead.
Eh I have to retract my
Herbert Xu wrote:
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
While we're here, I'll mention that dump_stack probably ought to take a
severity level argument.
125 files changed, 202 insertions(+), 199 deletions(-)
just to get the api change done.
I can hear akpm cringe from here...
You don't
Arjan van de Ven wrote:
Jeremy Fitzhardinge wrote:
Arjan van de Ven wrote:
This patch moves WARN_ON() out of line entirely. I've considered keeping
the test inline and moving only the slowpath out of line, but I decided
against that: an out of line test reduces the pressure on the CPUs
branch p
Jeremy Fitzhardinge wrote:
Arjan van de Ven wrote:
This patch moves WARN_ON() out of line entirely. I've considered keeping
the test inline and moving only the slowpath out of line, but I decided
against that: an out of line test reduces the pressure on the CPUs
branch predictor logic and gives
Ingo Molnar wrote:
> * Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
>
>> +#define WARN_ON(condition) do_warn_on((unsigned long)(condition), __FILE__,
>> \
>> + __LINE__, __FUNCTION__)
>>
>
> hm. This passes in 4 arguments to do_warn_on().
>
> i think we
Arjan van de Ven wrote:
> This patch moves WARN_ON() out of line entirely. I've considered keeping
> the test inline and moving only the slowpath out of line, but I decided
> against that: an out of line test reduces the pressure on the CPUs
> branch predictor logic and gives smaller code, while a
Arjan van de Ven пишет:
> Subject: move WARN_ON() out of line
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> CC: Ingo Molnar <[EMAIL PROTECTED]>
> CC: Andrew Morton <[EMAIL PROTECTED]>
>
> A quick grep shows that there are currently 1145 instances of WARN_ON
> in the kernel. Currently, WARN_ON is
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
>> While we're here, I'll mention that dump_stack probably ought to take a
>> severity level argument.
>
> 125 files changed, 202 insertions(+), 199 deletions(-)
> just to get the api change done.
> I can hear akpm cringe from here...
You don't have t
Matt Mackall wrote:
I hate the do_foo naming scheme (how about __warn_on?), but otherwise:
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
after I moved it around based on Olof's work, I've now ended up with
warn_on_slowpath()
+ printk(KERN_WARNING "WARNING: at %s:%d %s()\n",
+
Olof Johansson wrote:
On Thu, Jan 03, 2008 at 01:56:58AM +0100, Arjan van de Ven wrote:
Subject: move WARN_ON() out of line
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
A quick grep shows that there are currently 1145 insta
Ingo Molnar wrote:
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
+#define WARN_ON(condition) do_warn_on((unsigned long)(condition), __FILE__, \
+__LINE__, __FUNCTION__)
hm. This passes in 4 arguments to do_warn_on().
i think we could get away with no a
Hi Arjan,
On Jan 3, 2008 2:56 AM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> +int do_warn_on(const unsigned long condition, const char *file,
> + const int line, const char *function)
> +{
> + if (unlikely(condition)) {
> + printk(KERN_WARNING "WARNING:
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> +#define WARN_ON(condition) do_warn_on((unsigned long)(condition), __FILE__, \
> + __LINE__, __FUNCTION__)
hm. This passes in 4 arguments to do_warn_on().
i think we could get away with no arguments (!), by usi
On Thu, Jan 03, 2008 at 01:56:58AM +0100, Arjan van de Ven wrote:
> Subject: move WARN_ON() out of line
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> CC: Ingo Molnar <[EMAIL PROTECTED]>
> CC: Andrew Morton <[EMAIL PROTECTED]>
>
> A quick grep shows that there are currently 1145 instances of WARN_O
On Thu, 2008-01-03 at 01:56 +0100, Arjan van de Ven wrote:
> Subject: move WARN_ON() out of line
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> CC: Ingo Molnar <[EMAIL PROTECTED]>
> CC: Andrew Morton <[EMAIL PROTECTED]>
>
> A quick grep shows that there are currently 1145 instances of WARN_ON
> i
Subject: move WARN_ON() out of line
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
A quick grep shows that there are currently 1145 instances of WARN_ON
in the kernel. Currently, WARN_ON is pretty much entirely inlined,
which m
18 matches
Mail list logo
