From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754836AbaHUMvL (ORCPT ); Thu, 21 Aug 2014 08:51:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1996 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753475AbaHUMvJ (ORCPT ); Thu, 21 Aug 2014 08:51:09 -0400 Date: Thu, 21 Aug 2014 14:50:57 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Gleb Natapov , Raghavendra KT , Vinod Chegu , Hui-Zhi , Christian Borntraeger Subject: Re: [PATCH v2 1/6] KVM: add kvm_arch_sched_in Message-ID: <20140821125056.GE20453@potion.brq.redhat.com> References: <1408567997-21222-1-git-send-email-rkrcmar@redhat.com> <1408567997-21222-2-git-send-email-rkrcmar@redhat.com> <53F5ADF6.7060000@redhat.com> <20140821113801.GA20546@potion.brq.redhat.com> <53F5E5B1.6020106@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53F5E5B1.6020106@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2014-08-21 14:27+0200, Paolo Bonzini: > Il 21/08/2014 13:38, Radim Krčmář ha scritto: > > 2014-08-21 10:29+0200, Paolo Bonzini: > >> Il 20/08/2014 22:53, Radim Krčmář ha scritto: > >>> Introduce preempt notifiers for architecture specific code. > >>> Advantage over creating a new notifier in every arch is slightly simpler > >>> code and guaranteed call order with respect to kvm_sched_in. > >>> > >>> Signed-off-by: Radim Krčmář > >>> --- > >>> arch/arm/kvm/arm.c | 4 ++++ > >>> arch/mips/kvm/mips.c | 4 ++++ > >>> arch/powerpc/kvm/powerpc.c | 4 ++++ > >>> arch/s390/kvm/kvm-s390.c | 4 ++++ > >>> arch/x86/kvm/x86.c | 4 ++++ > >> > >> What about adding them as static inlines in > >> arch/*/include/asm/kvm_host.h (except for arch/x86 of course)? > > > > All empty arch functions are in '.c' files, so it seems better to follow > > the same path. > > (And have one refactoring patch if GCC does not optimize this.) > > GCC certainly does not optimize this (unless you use LTO). I see LTO patches in next ... do we want to move every empty arch function into headers? (It is probably going to take LTO few years to be enabled by default.)