[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20061016193140.GA6422@rhlx01.fht-esslingen.de>
Date: Mon, 16 Oct 2006 21:31:40 +0200
From: Andreas Mohr <andi@...x01.fht-esslingen.de>
To: Ralf Baechle <ralf@...ux-mips.org>
Cc: "Randy.Dunlap" <rdunlap@...otime.net>,
Andrew Morton <akpm@...l.org>,
Erik Frederiksen <erik_frederiksen@...-sierra.com>,
linux-kernel@...r.kernel.org
Subject: Re: IS_ERR Threshold Value
Hi,
On Thu, Jun 29, 2006 at 07:10:13PM +0100, Ralf Baechle wrote:
> On Wed, Jun 28, 2006 at 02:08:25PM -0700, Randy.Dunlap wrote:
>
> > Hi,
> > Peter Anvin mentioned just a few days ago that this threshold value
> > should be 4095 for all arches. I think we need to get that patch
> > done & submitted to Andrew for -mm.
>
> So here the patch is:
>
> o Raise the maximum error number in IS_ERR_VALUE to 4095.
> o Make that number available as a new constant MAX_ERRNO.
>
> Signed-off-by: Ralf Baechle <ralf@...ux-mips.org>
>
> diff --git a/include/linux/err.h b/include/linux/err.h
> index ff71d2a..cd3b367 100644
> --- a/include/linux/err.h
> +++ b/include/linux/err.h
> @@ -13,7 +13,9 @@ #include <asm/errno.h>
> * This should be a per-architecture thing, to allow different
> * error and pointer decisions.
> */
> -#define IS_ERR_VALUE(x) unlikely((x) > (unsigned long)-1000L)
> +#define MAX_ERRNO 4095
> +
> +#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
>
> static inline void *ERR_PTR(long error)
> {
# cat /proc/likely_prof |grep -v "^ "
Likely Profiling Results
[+- ] Type | # True | # False | Function:Filename@...e
+unlikely | 1872| 0 IS_ERR()@:include/linux/err.h@34
-likely | 88| 1033 remove_from_swapped_list()@:mm/swap_prefetch.c@140
-likely | 311| 2679 tcp_transmit_skb()@:net/ipv4/tcp_output.c@372
-likely | 0| 175176 __switch_to_xtra()@:arch/i386/kernel/process.c@569
+unlikely | 20| 19 remap_pte_range()@:mm/memory.c@...2
+unlikely | 9| 0 signal_pending()@:include/linux/sched.h@...3
+unlikely | 9| 0 signal_pending()@:include/linux/sched.h@...3
-likely | 15591| 44490 generic_file_buffered_write()@:mm/filemap.c@...0
+unlikely | 45| 0 ll_front_merge_fn()@:block/ll_rw_blk.c@...5
+unlikely | 1| 0 simple_pin_fs()@:fs/libfs.c@419
+unlikely | 216| 0 inotify_find_update_watch()@:fs/inotify.c@597
+unlikely | 1820| 0 get_locked_pte()@:mm/memory.c@...4
+unlikely | 82529| 0 ll_back_merge_fn()@:block/ll_rw_blk.c@...7
+unlikely | 416831| 116869 need_resched()@:include/linux/sched.h@...8
+unlikely | 28334365| 23531065 __lock_acquire()@:kernel/lockdep.c@...4
# uname -a
Linux andi 2.6.19-rc1-mm1 #1 Thu Oct 19 23:55:19 CEST 2006 i686 GNU/Linux
Athlon 1200, Debian
Hmmmmmm...
(I strongly believe I've seen this particular unlikely place trigger sometime
before already!)
Could this be because
+#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
should be made to be
#define IS_ERR_VALUE(x) unlikely((unsigned long)(x) >= (unsigned long)-MAX_ERRNO)
similar to what some other code in this discussion thread does?
(don't ask me which code is actually invoking this macro; obviously this
might be a problem due to unexpected (non-)failure which seems to be happening
here)
And some other (un)likely results here seem fishy as well, no matter
what kind of load I throw at my box... (pondering sending some patches
for the worst excesses). Any comments about those results above?
My results seem to strongly indicate that nobody else is doing unlikely
profiling??
Andreas Mohr
-
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