Hi, Jan,
I've just renewed the patch as you suggusted. Actually it isn't quite
performance sensitive, but the point is one less branch leads to
less penalty caused by branch prediction failure. Ok, this may be
way too paranoid.:-)
A bitwise flag comparison could be done using a more efficient b
On Thu 03-04-14 16:00:44, Zhan Jianyu wrote:
> On Thu, Apr 3, 2014 at 2:13 AM, Jan Kara wrote:
> > OK, but have you checked the generated code is actually any better? This
> > is something I'd expect a compiler might be able to optimize anyway. And the
> > original code looks more readable to me
On Thu, Apr 3, 2014 at 2:13 AM, Jan Kara wrote:
> OK, but have you checked the generated code is actually any better? This
> is something I'd expect a compiler might be able to optimize anyway. And the
> original code looks more readable to me.
Hi, Jan,
I've disassemble the code on my x86_64 b
On Wed 02-04-14 23:19:06, Jianyu Zhan wrote:
> A bitwise flag comparison could be done using a more efficient bit-ops way.
OK, but have you checked the generated code is actually any better? This
is something I'd expect a compiler might be able to optimize anyway. And the
original code looks more
A bitwise flag comparison could be done using a more efficient bit-ops way.
Signed-off-by: Jianyu Zhan
---
include/linux/blkdev.h | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1e1fa3f..adfa40a 100644
--- a
5 matches
Mail list logo