From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57565C10F13 for ; Tue, 16 Apr 2019 10:37:15 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 233F120693 for ; Tue, 16 Apr 2019 10:37:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JiKkUAuv"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="OvlQJlR5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 233F120693 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Cj8y2WZFsmjt755deQbaCba0lwrm9/1+NCD9IuQz6hs=; b=JiKkUAuviZ9l8Q bByNGTrGlroXHssJaj9J6Wkh28XtpVWcTWCfwqRtS0GFeRhWhdc6r1fIRiBy2ynXafmrLo0Cy+K5b ExxTRZ6/94TNKI2xaYbLGoGiR40GKN0YdkurqodKJMOYPiOIaLTfrEYTBR18BHwvOdSaQl+EMrBeJ Eqx9NBJmd6JmGDEab3zjYyK+JCrGWiUH6rXXdFo2i2/vVvZlcdy9FAEKusVWKdtur+xBe73wPqd1d nhEfdiFGz1xiO89EDXzU54Gtvav7TYPgUv8dD/HoU+lWE5lOQUWG8znSwsFEldMLvaIWvcbL/AX14 fa6D50hjlz099C1V/7YQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGLSb-0003Nx-Ff; Tue, 16 Apr 2019 10:37:05 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGLSY-0003NZ-I7 for linux-arm-kernel@lists.infradead.org; Tue, 16 Apr 2019 10:37:03 +0000 Received: by mail-wm1-x341.google.com with SMTP id z24so24834704wmi.5 for ; Tue, 16 Apr 2019 03:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=lJNEr0lgC5hOaWobOyR0GHw5gf2ZfjcSTpI7Aq88nOs=; b=OvlQJlR5Y9aVDgDXeb1ZO7/2qfjnVn2djKc3S2RQOUU2XyX6xtYsqm0eaBXuBSNs// UsKZEU37eQqtUtm1m6tBd77lxFOTnsGMHL1m2c1Y3mCzLbeA74qhepaqECfo3Tr8+RnR BAEuUtg/J0dNsmUZOIRxURtlw4yRCdp2JnELh9pExlY7rG+bR8NOALfsxr/HNmlouLTL V6wLsKJWykjhRvnASGzZ9dkr/eMddtkyZeMGVtdSb27onN09OAY0Ujz8Z1RNv69n11SM up+FOwBZ3nqmHBNsNSzSCaw8QJle7+QdZfLDqtrQTxBRh3tSee4uZnLXzQt1a5sWLpuD zGiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=lJNEr0lgC5hOaWobOyR0GHw5gf2ZfjcSTpI7Aq88nOs=; b=XyPYfxZIgBYWNpPFUTX5l3y/W2FY4hUuE5/mRFj4ZEOPcTFxlRoklV7BhaJC+XlPNQ scLhzvaiXca0Vsu/2RXQVBzVNyFz3L2snSV61iQHVZDlXP76FPNnJ2WCnEFB2VT8m8qy 3tYA23Qjw4Go9xwFct9mA/YVw/nLPLcIAT3F+hiaORVEFTX7T8NRxdQ6mXEnjwXih6+y UrAhNLn4pOTOHIM5GjKsS5L8JGRaot1pw/zmudlKmRCOjr6QLB8ziMo0PMhUGn3R4qWg FlNAirdPcKUViSCtbSzwU+t83CtSJ+5gT+Vl1/JCRRvY4p/SNuqXGxebxaV2sw98Tp13 wH5Q== X-Gm-Message-State: APjAAAVrR3XBPj5Yt6Fn5NNBV372NnaB2/I2z8iNteJ7JPsCObfmmO6B wnhzsDBIWBpPdTJnhfI/86kbUaelYIQ= X-Google-Smtp-Source: APXvYqxPj+BaF6wCz/4xVU8s8Nqmmi/xX1RgUDVirDFai5ITMlpSdp1biVHjoBHpzbjvJLAPx0Ya+A== X-Received: by 2002:a1c:1b45:: with SMTP id b66mr26677777wmb.77.1555411020871; Tue, 16 Apr 2019 03:37:00 -0700 (PDT) Received: from localhost ([78.133.233.210]) by smtp.gmail.com with ESMTPSA id d16sm43918891wrs.68.2019.04.16.03.37.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 03:37:00 -0700 (PDT) Date: Tue, 16 Apr 2019 12:32:16 +0200 From: Marek Bykowski To: Sudeep Holla Subject: Re: L3 cache way-locking memory zone Message-ID: <20190416123216.04a89bd3@gmail.com> In-Reply-To: <20190415140645.GA24249@e107155-lin> References: <20190415153849.358d78a9@gmail.com> <20190415140645.GA24249@e107155-lin> Organization: vvsnsbwbwyrlmlpo X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190416_033702_602257_67AB3315 X-CRM114-Status: GOOD ( 11.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Sudeep, To me it is quite generic but I don't have an experience working on a broad range of ARM products. It works more less along this: one needs to set up an SMC service allowing querying the L3 way-locking registers/configuration from within kernel. The L3 way-locking is configured itself statically in SPL Uboot running EL3, secure state. The static configuration is a result of the constraint on when and how the registers can be accessed, namely "normal"/memory access to HN-F cannot be in-flight while the write to these registers occur - to my best knowledge we cannot meet that with the system/Linux up and running. The secure state results from the L3 lock registers being only accessed from the secure. After then when Linux boots it does the SMC call to query whether there is the L3 way-locking in place and what base addresses and the sizes and it sets up the zone upon it. The following are some confs/printouts from the Linux having 2G of RAM, and 24M of LLC with 16M configured to locked: zone_size[0] 131072 zhole_size[0] 0 zone_size[1] 4096 zhole_size[1] 0 zone_size[2] 389120 zhole_size[2] 0 zone_size[3] 0 zhole_size[3] 0 L3LOCKED zone: 64 pages used for memmap L3LOCKED zone: 4096 pages, LIFO batch:0 mem_init() DMA->managed_pages 129024 mem_init() L3LOCK->managed_pages 4032 mem_init() Normal->managed_pages 383040 mem_init() Movable->managed_pages 0 And after releasing free pages to the buddy allocator mem_init() DMA->managed_pages 123787 mem_init() L3LOCK->managed_pages 4096 mem_init() Normal->managed_pages 379305 mem_init() Movable->managed_pages 0 # cat /proc/buddyinfo (reformatted to squeeze) Node 0, zone DMA 4 4 3 4 2 3 2 4 2 3 122 Node 0, zone L3LOCK 0 0 0 0 0 0 0 0 0 0 4 Node 0, zone Normal 21 3 7 2 2 1 1 1 1 2 306 # cat /proc/slabinfo [...] Node 0, zone L3LOCK pages free 4096 min 135 low 168 high 201 node_scanned 0 spanned 4096 present 4096 managed 4096 Then we can allocate to the L3LOCK zone with 'kmalloc(size, GFP_L3LOCK)'. We have used the L3LOCK to benchmark the DMA that presented the better results when copying from L3 locked to L3 locked than from "unlocked" to "unlocked". Thanks, Marek _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel