From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752576AbcF2B5p (ORCPT ); Tue, 28 Jun 2016 21:57:45 -0400 Received: from smtprelay0101.hostedemail.com ([216.40.44.101]:43891 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752494AbcF2B5n (ORCPT ); Tue, 28 Jun 2016 21:57:43 -0400 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::,RULES_HIT:41:355:379:541:599:800:960:968:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2553:2559:2562:2693:2731:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3868:3870:3871:3872:3874:5007:6261:7875:8531:8603:10004:10400:10848:10967:11026:11232:11658:11914:12517:12519:12663:12740:13069:13138:13160:13161:13229:13231:13311:13357:13439:14096:14097:14181:14659:14721:21080:21434,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:2,LUA_SUMMARY:none X-HE-Tag: stick46_42df9e64e5d3a X-Filterd-Recvd-Size: 2529 Date: Tue, 28 Jun 2016 21:57:38 -0400 From: Steven Rostedt To: Namhyung Kim Cc: Ingo Molnar , LKML , Subject: Re: [RFC/PATCH v2] ftrace: Reduce size of function graph entries Message-ID: <20160628215738.6e4815dd@gandalf.local.home> In-Reply-To: <20160629013234.GA1628@sejong> References: <1467091840-4625-1-git-send-email-namhyung@kernel.org> <20160628193200.71629fc5@gandalf.local.home> <20160629013234.GA1628@sejong> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 Jun 2016 10:32:34 +0900 Namhyung Kim wrote: > > is at 32-37 > > > > For a total of 38 bytes. I'm betting that without the packed, the 4 > > extra bytes will always be at the end. > > Woundn't it be 36 or 40 bytes? :) Ug, don't know what I was counting then. I added the 64 bit version as a after thought. > > > > > If the compiler places it incorrectly without any attribute, it will > > fail to read the long long if the arch requires 64 bits to be 8 bytes > > aligned. The alignment is meaningless here. All we need is "packed" and > > be done with it. It's only going to truncate the 4 bytes at the end of > > the structure if that. > > I agree that in-struct alignment preserved without the 'aligned' > attribute but I'm not sure whether it's guaranteed that the *start* > address of the struct is still in proper alignment boundary. > > IOW the struct ftrace_graph_ret should be placed at 8-byte boundary in order > to keep alignment of struct members. Is it guaranteed after applying > 'packed'? > My point is, a structure doesn't change size depending on where it is located. Thus, if a structure contains a 8 byte field, that must be 8 bytes aligned due to architecture constraints, then it had better be aligned that way everywhere. If it is not, then accessing the 8 byte fields will cause issues. The only thing that the "packed" changes, is it removes the last 4 padded bytes of the structure. It doesn't change anything else. Hence, the alignment is just extra and unneeded. -- Steve