Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752140AbaKGGnh (ORCPT ); Fri, 7 Nov 2014 01:43:37 -0500 Received: from ppsw-51.csi.cam.ac.uk ([131.111.8.151]:56719 "EHLO ppsw-51.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751334AbaKGGne convert rfc822-to-8bit (ORCPT ); Fri, 7 Nov 2014 01:43:34 -0500 X-Greylist: delayed 8429 seconds by postgrey-1.27 at vger.kernel.org; Fri, 07 Nov 2014 01:43:32 EST X-Cam-AntiVirus: found ScamNailer.Phish.viro_AT_zeniv.linux.org.uk X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Subject: Re: [fuse-devel] [PATCH v5 7/7] add a flag for per-operation O_DSYNC semantics Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: text/plain; charset=us-ascii From: Anton Altaparmakov In-Reply-To: Date: Fri, 7 Nov 2014 08:43:00 +0200 Cc: Jeff Moyer , linux-arch@vger.kernel.org, linux-aio@kvack.org, linux-nfs@vger.kernel.org, Volker Lendecke , "Theodore Ts'o" , linux-mm@kvack.org, "fuse-devel@lists.sourceforge.net" , linux-api@vger.kernel.org, Linux Kernel Mailing List , Al Viro , Christoph Hellwig , Tejun Heo , Milosz Tanski , linux-fsdevel@vger.kernel.org, Michael Kerrisk , ceph-devel@vger.kernel.org, Christoph Hellwig , ocfs2-devel@oss.oracle.com, Mel Gorman Content-Transfer-Encoding: 8BIT Message-Id: References:

To: Anand Avati X-Mailer: Apple Mail (2.1990.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > On 7 Nov 2014, at 07:52, Anand Avati wrote: > On Thu, Nov 6, 2014 at 8:22 PM, Anton Altaparmakov wrote: > > On 7 Nov 2014, at 01:46, Jeff Moyer wrote: > > Minor nit, but I'd rather read something that looks like this: > > > > if (type == READ && (flags & RWF_NONBLOCK)) > > return -EAGAIN; > > else if (type == WRITE && (flags & RWF_DSYNC)) > > return -EINVAL; > > But your version is less logically efficient for the case where "type == READ" is true and "flags & RWF_NONBLOCK" is false because your version then has to do the "if (type == WRITE" check before discovering it does not need to take that branch either, whilst the original version does not have to do such a test at all. > > Seriously? Of course seriously. > Just focus on the code readability/maintainability which makes the code most easily understood/obvious to a new pair of eyes, and leave such micro-optimizations to the compiler.. The original version is more readable (IMO) and this is not a micro-optimization. It is people like you who are responsible for the fact that we need faster and faster computers to cope with the inefficient/poor code being written more and more... And I really wouldn't hedge my bets on gcc optimizing something like that. The amount of crap assembly produced from gcc that I have seen over the years suggests that it is quite likely it will make a hash of it instead... Best regards, Anton > Thanks -- Anton Altaparmakov (replace at with @) University of Cambridge Information Services, Roger Needham Building 7 JJ Thomson Avenue, Cambridge, CB3 0RB, UK -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/