From patchwork Wed Sep 30 17:30:34 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rasmus Villemoes X-Patchwork-Id: 7301071 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id DBD81BEEA4 for ; Wed, 30 Sep 2015 17:31:03 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 12AF5204AD for ; Wed, 30 Sep 2015 17:31:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2F409204A9 for ; Wed, 30 Sep 2015 17:31:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933259AbbI3Ran (ORCPT ); Wed, 30 Sep 2015 13:30:43 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:38872 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932481AbbI3Rai (ORCPT ); Wed, 30 Sep 2015 13:30:38 -0400 Received: by wiclk2 with SMTP id lk2so72654613wic.1 for ; Wed, 30 Sep 2015 10:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=from:to:cc:subject:organization:date:message-id:user-agent :mime-version:content-type; bh=osQj/4ilAvTXgD68PiqDCWYlw3NdtNRZzozTWu92OBg=; b=QuWeJXSgLpAZNUtMBdX1Gz1ExdBLAb4jlYrzedmjM68RKzirfS06oHFuWfFNel06/B /FHy+SvOkPnUMTwJ13KBQIest+WOciiSClwzyUjjw3KTZ+8DFvcYZ1EuBFAAPbU/4TbT rw3rOOZ9GLuTog/inMm2DMJ/W4Qa8XEm6vxC0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:date:message-id :user-agent:mime-version:content-type; bh=osQj/4ilAvTXgD68PiqDCWYlw3NdtNRZzozTWu92OBg=; b=SVq6+TcP3PBbHoxXqByxHxRkCum6iDjBstPEpY7D5T4xmDoPXpLkhfOUQyVuozOYww 0YIb4yFtc5PZV5r5iFFF+ASehDhH9t9riMxxq28qO6uoOEh8f32S5jyMEefgPBruw+75 eBOoXNbTngSP3NqCotmf6hrQ5aI3kMbb/p13sArwGuxqjdvaoow3jin1xtB8hXxND9RH v/vpi3U6F4jKABoENBtoEThMCqtw9YzmgBy4l3YahNk01uEV03So41Ga7S2RLPYUmVw+ 39tcRj5eQ7EjWEISG6RYfUKLG2omrpi1IDRQW8T3QI2xKhJdv3VhCCqM5wM02zsbuVKd 4ePg== X-Gm-Message-State: ALoCoQlGEOrJMr/uuQTRwTCTqzwuPPP0BN3VuO4qGJlgWnHbIfupftJo8tB8oq8s4BFucxnGk/6/ X-Received: by 10.194.192.6 with SMTP id hc6mr5512057wjc.33.1443634236906; Wed, 30 Sep 2015 10:30:36 -0700 (PDT) Received: from morgan.rasmusvillemoes.dk (ip-45-63.bnaa.dk. [84.238.45.63]) by smtp.gmail.com with ESMTPSA id gt4sm30702984wib.21.2015.09.30.10.30.36 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 30 Sep 2015 10:30:36 -0700 (PDT) From: Rasmus Villemoes To: Christoph Hellwig , Hannes Reinecke , "James E.J. Bottomley" Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org Subject: RFC: reduce CONFIG_SCSI_CONSTANTS impact by 4k Organization: D03 X-Hashcash: 1:20:150930:linux-kernel@vger.kernel.org::ErJutXlhMpPjLTe4:00000000000000000000000000000000024jh Date: Wed, 30 Sep 2015 19:30:34 +0200 Message-ID: <87h9mbg6h1.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP struct error_info has 6 bytes of padding on x86_64 (and I assume also other 64 bit platforms). This currently amounts to about 4k of wasted space (and presumably a third of that on 32 bit). We can avoid that by keeping the codes and the strings in separate arrays. Keeping those in sync should be easy enough if we use the standard trick of including a table twice. Patch 2/2 would be something like below; 1/2 is a 1600 line purely mechanical thing which I won't spam the lists with unless someone else thinks this is a good idea. What do you think? Subject: [PATCH 2/2] scsi: split additional[] array in two struct error_info has 6 bytes of padding (on 64 bit platforms), which amounts to over 4K of wasted space in the additional[] array. Splitting it in two avoids that waste. A BUILD_BUG_ON and the fact that the two arrays are generated from the same include file should keep these two arrays in sync. $ scripts/bloat-o-meter /tmp/vmlinux vmlinux add/remove: 2/1 grow/shrink: 1/0 up/down: 7073/-11312 (-4239) Signed-off-by: Rasmus Villemoes --- drivers/scsi/constants.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c index 14d5069ca3ff..03f28cdcbc31 100644 --- a/drivers/scsi/constants.c +++ b/drivers/scsi/constants.c @@ -290,19 +290,19 @@ bool scsi_opcode_sa_name(int opcode, int service_action, return true; } -struct error_info { - unsigned short code12; /* 0x0302 looks better than 0x03,0x02 */ - const char * text; +static unsigned short additional_code12[] = { +#define SENSE_CODE(c, s) c +#include "sense_codes.h" +#undef SENSE_CODE }; - -static const struct error_info additional[] = -{ -#define SENSE_CODE(c, s) {c, s} +static const char *additional_text[] = { +#define SENSE_CODE(c, s) s #include "sense_codes.h" #undef SENSE_CODE }; + struct error_info2 { unsigned char code1, code2_min, code2_max; const char * str; @@ -364,11 +364,12 @@ scsi_extd_sense_format(unsigned char asc, unsigned char ascq, const char **fmt) { int i; unsigned short code = ((asc << 8) | ascq); + BUILD_BUG_ON(ARRAY_SIZE(additional_code12) != ARRAY_SIZE(additional_text)); *fmt = NULL; - for (i = 0; additional[i].text; i++) - if (additional[i].code12 == code) - return additional[i].text; + for (i = 0; additional_text[i]; i++) + if (additional_code12[i] == code) + return additional_text[i]; for (i = 0; additional2[i].fmt; i++) { if (additional2[i].code1 == asc && ascq >= additional2[i].code2_min &&