From: Vlastimil Babka <vbabka@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Roman Gushchin <guro@fb.com>, Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-api@vger.kernel.org, Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>,
Mel Gorman <mgorman@techsingularity.net>,
Matthew Wilcox <willy@infradead.org>,
Laura Abbott <labbott@redhat.com>,
Sumit Semwal <sumit.semwal@linaro.org>,
Vijayanand Jitta <vjitta@codeaurora.org>
Subject: Re: [PATCH v2 0/7] kmalloc-reclaimable caches
Date: Tue, 19 Jun 2018 09:54:54 +0200 [thread overview]
Message-ID: <386fda93-a2d4-6302-c233-12bc77c7668c@suse.cz> (raw)
In-Reply-To: <20180618091808.4419-1-vbabka@suse.cz>
On 06/18/2018 11:18 AM, Vlastimil Babka wrote:
> v2 changes:
> - shorten cache names to kmalloc-rcl-<SIZE>
> - last patch shortens <SIZE> for all kmalloc caches to e.g. "1k", "4M"
> - include dma caches to the 2D kmalloc_caches[] array to avoid a branch
> - vmstat counter nr_indirectly_reclaimable_bytes renamed to
> nr_kernel_misc_reclaimable, doesn't include kmalloc-rcl-*
> - /proc/meminfo counter renamed to KReclaimable, includes kmalloc-rcl*
> and nr_kernel_misc_reclaimable
>
> Hi,
>
> as discussed at LSF/MM [1] here's a patchset that introduces
> kmalloc-reclaimable caches (more details in the second patch) and uses them for
> SLAB freelists and dcache external names. The latter allows us to repurpose the
> NR_INDIRECTLY_RECLAIMABLE_BYTES counter later in the series.
More info about user benefits of the patchset:
With patch 4, dcache external names are allocated from kmalloc-rcl-*
caches, eliminating the need for manual accounting. More importantly, it
also ensures the reclaimable kmalloc allocations are grouped in pages
separate from the regular kmalloc allocations. The need for proper
accounting of dcache external names has shown it's easy for misbehaving
process to allocate lots of them, causing premature OOMs. Without the
added grouping, it's likely that similar workload can interleave the
dcache external names allocations with regular kmalloc allocations
(note: I haven't searched myself for an example of such regular kmalloc
allocation, but I would be very surprised if there wasn't some). A
pathological case would be e.g. one 64byte regular allocations with 63
external dcache names in a page (64x64=4096), which means the page is
not freed even after reclaiming after all dcache names, and the process
can thus steal the whole page with single 64byte allocation.
If there other kmalloc users similar to dcache external names become
identified, they can also benefit from the new functionality simply by
adding __GFP_RECLAIMABLE to the kmalloc calls.
Side benefits of the patchset (that could be also merged separately)
include removed branch for detecting __GFP_DMA kmalloc(), and shortening
kmalloc cache names in /proc/slabinfo output. The latter is potentially
an ABI break in case there are tools parsing the names and expecting the
values to be in bytes.
prev parent reply other threads:[~2018-06-19 7:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-18 9:18 Vlastimil Babka
2018-06-18 9:18 ` [PATCH v2 1/7] mm, slab: combine kmalloc_caches and kmalloc_dma_caches Vlastimil Babka
2018-06-18 9:18 ` [PATCH v2 2/7] mm, slab/slub: introduce kmalloc-reclaimable caches Vlastimil Babka
2018-06-18 9:18 ` [PATCH v2 3/7] mm, slab: allocate off-slab freelists as reclaimable when appropriate Vlastimil Babka
2018-06-18 9:18 ` [PATCH v2 4/7] dcache: allocate external names from reclaimable kmalloc caches Vlastimil Babka
2018-06-18 9:18 ` [PATCH v2 5/7] mm: rename and change semantics of nr_indirectly_reclaimable_bytes Vlastimil Babka
2018-06-20 11:23 ` kbuild test robot
2018-06-29 15:37 ` Vlastimil Babka
2018-06-29 21:12 ` Roman Gushchin
2018-06-30 10:09 ` Vlastimil Babka
2018-07-02 16:52 ` Roman Gushchin
2018-07-17 8:44 ` Vlastimil Babka
2018-07-17 18:54 ` Roman Gushchin
2018-07-17 19:11 ` Vlastimil Babka
2018-06-18 9:18 ` [PATCH v2 6/7] mm, proc: add KReclaimable to /proc/meminfo Vlastimil Babka
2018-06-18 21:33 ` Andrew Morton
2018-06-19 7:30 ` Vlastimil Babka
2018-06-19 8:13 ` Minchan Kim
2018-06-19 12:44 ` Vlastimil Babka
2018-06-18 9:18 ` [PATCH v2 7/7] mm, slab: shorten kmalloc cache names for large sizes Vlastimil Babka
2018-06-19 7:54 ` Vlastimil Babka [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=386fda93-a2d4-6302-c233-12bc77c7668c@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=labbott@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=rientjes@google.com \
--cc=sumit.semwal@linaro.org \
--cc=vjitta@codeaurora.org \
--cc=willy@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