From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755380AbcASObN (ORCPT ); Tue, 19 Jan 2016 09:31:13 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:22169 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753920AbcASObG (ORCPT ); Tue, 19 Jan 2016 09:31:06 -0500 X-IronPort-AV: E=Sophos;i="5.22,317,1449532800"; d="scan'208";a="332411879" Subject: Re: [Xen-devel] [PATCH] xen/gntdev: Don't allocate struct gntdev_copy_batch on stack To: Boris Ostrovsky , References: <1452887025-27285-1-git-send-email-boris.ostrovsky@oracle.com> <569CC84A.1000401@citrix.com> <569E4784.10602@oracle.com> CC: , From: David Vrabel Message-ID: <569E48A7.8060408@citrix.com> Date: Tue, 19 Jan 2016 14:31:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <569E4784.10602@oracle.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/01/16 14:26, Boris Ostrovsky wrote: > On 01/18/2016 06:11 AM, David Vrabel wrote: >> On 15/01/16 19:43, Boris Ostrovsky wrote: >>> struct gntdev_copy_batch is over 1300 bytes in size, we shouldn't >>> put it on stack. >>> >>> Some compilers (e.g. 5.2.1) complain: >>> drivers/xen/gntdev.c: In function ‘gntdev_ioctl_grant_copy.isra.5’: >>> drivers/xen/gntdev.c:949:1: warning: the frame size of 1416 bytes >>> is larger than 1024 bytes [-Wframe-larger-than=] >> I thought I'd already reduced the size of this enough (from a batch size >> of 32 to 24) but this obviously isn't enough for 64-bit platforms. >> >> In the absence of any performance data on the best approach I would >> prefer just reducing the batch size to 16. > > That would still leave us with over 900 bytes on the stack which I think > is rather high. The stack depth to here isn't very deep, so I think even the ~1500 byte frame was fine. > Do we expect this ioctl to be on some sort of a hot path? Yes. David