From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [PATCH 1/2] mm, Make __get_user_pages return -EHWPOISON for HWPOISON page optionally Date: Fri, 28 Jan 2011 01:57:11 +0100 Message-ID: <20110128005711.GB15569@one.firstfloor.org> References: <1294908168.4596.58.camel@yhuang-dev> <4D2ED737.6050802@redhat.com> <1294969036.4596.67.camel@yhuang-dev> <4D331054.4030206@redhat.com> <1295225259.10748.3.camel@yhuang-dev> <20110120155021.GA5996@amt.cnet> <1296113345.15213.87.camel@yhuang-dev> <20110127150705.f2cfe235.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Huang Ying , Linus Torvalds , Avi Kivity , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , Andi Kleen , "Luck, Tony" , Dean Nelson , Marcelo Tosatti To: Andrew Morton Return-path: Content-Disposition: inline In-Reply-To: <20110127150705.f2cfe235.akpm@linux-foundation.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org I personally would consider it cleaner to have clearly defined wrappers instead of complicted flags in the caller. > The number of args to these functions is getting nutty - you'll > probably find that it is beneficial to inline these wrapepr functions, if > the number of callsites is small. Really the functions are so heavy weight it should not matter. The problem with inlining is that you end up with the code in the header file and I personally find that much harder to browse instead of having everything in one file. Also longer term we'll get compilers that can do cross-file inlining for optimized builds. So please better avoid these kinds of micro optimizations unless it's a really really extremly speed critical path. Thanks, -Andi -- ak@linux.intel.com -- Speaking for myself only.