[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <058f01c7998e$1406e370$650df7cd@MUMBA>
Date: Fri, 18 May 2007 16:49:49 -0400
From: "Alex Volkov" <avcp-lkmail@....net>
To: "'Andrew Morton'" <akpm@...ux-foundation.org>,
"'Jeff Garzik'" <jeff@...zik.org>
Cc: "'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>
Subject: RE: aio is unlikely
Andrew Morton wrote:
> aio is unlikely
> Stick an unlikely() around is_aio(): I assert that most IO is
synchronous.
>
> -#define in_aio() !is_sync_wait(current->io_wait)
> +#define in_aio() (unlikely(!is_sync_wait(current->io_wait)))
> Jeff Garzik <jeff@...zik.org> wrote:
>
> > > -#define in_aio() !is_sync_wait(current->io_wait)
> > > +#define in_aio() (unlikely(!is_sync_wait(current->io_wait)))
> >
> > Please revert. Workload-dependent "likelihood" should not cause
> > programmers to add such markers.
> a) disagree with the above
>
> b) if in_aio() ever returns true we do
>
> printk(KERN_ERR "%s(%s:%d) called in async context!\n",
> __FUNCTION__, __FILE__, __LINE__);
>
> so I sure hope it's unlikely for all workloads.
Shouldn't unlikely() go where in_aio() is actually used, if we printk(error)
there?
Isn't putting likely/unlikely into a boolean function-like macro itself
asking for later trouble?
--Alex.
-
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