public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: iamjoonsoo.kim@lge.com (Joonsoo Kim)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Increase the max granular size
Date: Tue, 10 Nov 2015 09:19:50 +0900	[thread overview]
Message-ID: <20151110001949.GA13894@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <20151109183608.GG21606@e104818-lin.cambridge.arm.com>

On Mon, Nov 09, 2015 at 06:36:09PM +0000, Catalin Marinas wrote:
> On Mon, Nov 09, 2015 at 04:41:58PM +0900, Joonsoo Kim wrote:
> > 2015-11-05 21:17 GMT+09:00 Catalin Marinas <catalin.marinas@arm.com>:
> > > On Thu, Nov 05, 2015 at 08:45:08PM +0900, Joonsoo Kim wrote:
> > >> If it isn't possible, is there another way to reduce memory waste due to
> > >> increase of dma alignment requirement in arm64?
> > >
> > > I first need to see how significant the impact is (especially for
> > > embedded/mobiles platforms).
> > 
> > I don't have any ARM64 device. What I have just one report
> > about slab usage from our developer.
> > 
> > The report shows slab usage just after android boot is done
> > in ARM64.
> > 
> > Total slab usage: 90 MB
> > kmalloc usage: 25 MB
> > kmalloc (<=64) usage: 7 MB
> > 
> > This would be measured without slab_nomerge so there is
> > a possibility that some usages on kmem_cache is merged
> > into usage of kmalloc (<=64).
> > 
> > Anyway, if ARM64 increase L1_CACHE_BYTES to 128, roughly
> > 7 MB would be wasted. I don't know how this picture is varied
> > in runtime, but, even boot time overhead, 7 MB looks large to me.
> 
> 7MB is considerable but I guess it wouldn't be all wasted with
> L1_CACHE_BYTES == 128, maybe half or slightly over. It would be good to
> know the other kmalloc caches, maybe up to 256.
> 
> I don't have an Android filesystem but I just tried to boot Arch
> (aarch64). Immediately after boot and slab_nomerge, with 128 L1 I get:
> 
> kmalloc-128:	6624
> kmalloc-256:	1488
> 
> With L1 64, I get:
> 
> kmalloc-64:	5760
> kmalloc-128:	1152
> kmalloc-192:	1155
> kmalloc-256:	 320
> 
> So that's about 1.2MB vs 0.8MB. The ratio is 3:2, though I'm not sure it
> will stay the same as the slab usage increases.
> 
> It would be good to get more numbers, we could add a Kconfig option just
> for specific builds while keeping the default to 128.

Okay.

Thanks.

      reply	other threads:[~2015-11-10  0:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22 17:59 [PATCH] arm64: Increase the max granular size Robert Richter
2015-09-22 18:29 ` Will Deacon
2015-09-25 14:45   ` Robert Richter
2015-09-25 16:31     ` Tirumalesh Chalamarla
2015-10-10 17:39 ` Timur Tabi
2015-10-12  9:16   ` Will Deacon
2015-10-16 19:57 ` Timur Tabi
2015-10-28 19:09 ` Catalin Marinas
     [not found]   ` <CAMuHMdWQygbxMXoOsbwek6DzZcr7J-C23VCK4ubbgUr+zj=giw@mail.gmail.com>
2015-11-03 12:05     ` Catalin Marinas
2015-11-03 14:38       ` Catalin Marinas
2015-11-03 14:55         ` Geert Uytterhoeven
2015-11-03 18:50           ` Catalin Marinas
2015-11-03 23:33             ` Christoph Lameter
2015-11-04 12:36               ` Catalin Marinas
2015-11-04 13:53                 ` Christoph Lameter
2015-11-04 14:54                   ` Catalin Marinas
2015-11-04 15:28                     ` Christoph Lameter
2015-11-04 15:39                       ` Catalin Marinas
2015-11-05  4:31                         ` Joonsoo Kim
2015-11-05 11:50                           ` [PATCH] mm: slab: Only move management objects off-slab for sizes larger than KMALLOC_MIN_SIZE Catalin Marinas
2015-11-05 13:31                             ` Andrew Morton
2015-11-05 16:08                               ` Catalin Marinas
2015-11-06 13:00                                 ` Geert Uytterhoeven
2015-11-05 17:39                             ` Christoph Lameter
2015-11-05  4:40 ` [PATCH] arm64: Increase the max granular size Joonsoo Kim
2015-11-05 10:32   ` Catalin Marinas
2015-11-05 11:45     ` Joonsoo Kim
2015-11-05 12:17       ` Catalin Marinas
2015-11-09  7:41         ` Joonsoo Kim
2015-11-09 18:36           ` Catalin Marinas
2015-11-10  0:19             ` Joonsoo Kim [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151110001949.GA13894@js1304-P5Q-DELUXE \
    --to=iamjoonsoo.kim@lge.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox