The patch titled Subject: mm: add /sys/kernel/slab/cache/cache_dma32 has been added to the -mm tree. Its filename is mm-add-sys-kernel-slab-cache-cache_dma32.patch
This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-add-sys-kernel-slab-cache-cache_... and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-add-sys-kernel-slab-cache-cache_...
Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated there every 3-4 working days
------------------------------------------------------ From: Nicolas Boichat drinkcat@chromium.org Subject: mm: add /sys/kernel/slab/cache/cache_dma32
A previous patch in this series adds support for SLAB_CACHE_DMA32 kmem caches. This adds the corresponding /sys/kernel/slab/cache/cache_dma32 entries, and fixes slabinfo tool.
Link: http://lkml.kernel.org/r/20181210011504.122604-4-drinkcat@chromium.org Signed-off-by: Nicolas Boichat drinkcat@chromium.org Cc: Christoph Hellwig hch@infradead.org Cc: Christoph Lameter cl@linux.com Cc: David Rientjes rientjes@google.com Cc: Hsin-Yi Wang hsinyi@chromium.org Cc: Huaisheng Ye yehs1@lenovo.com Cc: Joerg Roedel joro@8bytes.org Cc: Joonsoo Kim iamjoonsoo.kim@lge.com Cc: Matthew Wilcox willy@infradead.org Cc: Matthias Brugger matthias.bgg@gmail.com Cc: Mel Gorman mgorman@techsingularity.net Cc: Michal Hocko mhocko@suse.com Cc: Mike Rapoport rppt@linux.vnet.ibm.com Cc: Pekka Enberg penberg@kernel.org Cc: Robin Murphy robin.murphy@arm.com Cc: Sasha Levin Alexander.Levin@microsoft.com Cc: Tomasz Figa tfiga@google.com Cc: Vlastimil Babka vbabka@suse.cz Cc: Will Deacon will.deacon@arm.com Cc: Yingjoe Chen yingjoe.chen@mediatek.com Cc: Yong Wu yong.wu@mediatek.com Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton akpm@linux-foundation.org ---
Documentation/ABI/testing/sysfs-kernel-slab | 9 +++++++++ mm/slub.c | 11 +++++++++++ tools/vm/slabinfo.c | 7 ++++++- 3 files changed, 26 insertions(+), 1 deletion(-)
--- a/Documentation/ABI/testing/sysfs-kernel-slab~mm-add-sys-kernel-slab-cache-cache_dma32 +++ a/Documentation/ABI/testing/sysfs-kernel-slab @@ -106,6 +106,15 @@ Description: are from ZONE_DMA. Available when CONFIG_ZONE_DMA is enabled.
+What: /sys/kernel/slab/cache/cache_dma32 +Date: December 2018 +KernelVersion: 4.21 +Contact: Nicolas Boichat drinkcat@chromium.org +Description: + The cache_dma32 file is read-only and specifies whether objects + are from ZONE_DMA32. + Available when CONFIG_ZONE_DMA32 is enabled. + What: /sys/kernel/slab/cache/cpu_slabs Date: May 2007 KernelVersion: 2.6.22 --- a/mm/slub.c~mm-add-sys-kernel-slab-cache-cache_dma32 +++ a/mm/slub.c @@ -5112,6 +5112,14 @@ static ssize_t cache_dma_show(struct kme SLAB_ATTR_RO(cache_dma); #endif
+#ifdef CONFIG_ZONE_DMA32 +static ssize_t cache_dma32_show(struct kmem_cache *s, char *buf) +{ + return sprintf(buf, "%d\n", !!(s->flags & SLAB_CACHE_DMA32)); +} +SLAB_ATTR_RO(cache_dma32); +#endif + static ssize_t usersize_show(struct kmem_cache *s, char *buf) { return sprintf(buf, "%u\n", s->usersize); @@ -5452,6 +5460,9 @@ static struct attribute *slab_attrs[] = #ifdef CONFIG_ZONE_DMA &cache_dma_attr.attr, #endif +#ifdef CONFIG_ZONE_DMA32 + &cache_dma32_attr.attr, +#endif #ifdef CONFIG_NUMA &remote_node_defrag_ratio_attr.attr, #endif --- a/tools/vm/slabinfo.c~mm-add-sys-kernel-slab-cache-cache_dma32 +++ a/tools/vm/slabinfo.c @@ -29,7 +29,7 @@ struct slabinfo { char *name; int alias; int refs; - int aliases, align, cache_dma, cpu_slabs, destroy_by_rcu; + int aliases, align, cache_dma, cache_dma32, cpu_slabs, destroy_by_rcu; unsigned int hwcache_align, object_size, objs_per_slab; unsigned int sanity_checks, slab_size, store_user, trace; int order, poison, reclaim_account, red_zone; @@ -534,6 +534,8 @@ static void report(struct slabinfo *s) printf("** Hardware cacheline aligned\n"); if (s->cache_dma) printf("** Memory is allocated in a special DMA zone\n"); + if (s->cache_dma32) + printf("** Memory is allocated in a special DMA32 zone\n"); if (s->destroy_by_rcu) printf("** Slabs are destroyed via RCU\n"); if (s->reclaim_account) @@ -602,6 +604,8 @@ static void slabcache(struct slabinfo *s *p++ = '*'; if (s->cache_dma) *p++ = 'd'; + if (s->cache_dma32) + *p++ = 'D'; if (s->hwcache_align) *p++ = 'A'; if (s->poison) @@ -1208,6 +1212,7 @@ static void read_slab_dir(void) slab->aliases = get_obj("aliases"); slab->align = get_obj("align"); slab->cache_dma = get_obj("cache_dma"); + slab->cache_dma32 = get_obj("cache_dma32"); slab->cpu_slabs = get_obj("cpu_slabs"); slab->destroy_by_rcu = get_obj("destroy_by_rcu"); slab->hwcache_align = get_obj("hwcache_align"); _
Patches currently in -mm which might be from drinkcat@chromium.org are
mm-add-support-for-kmem-caches-in-dma32-zone.patch iommu-io-pgtable-arm-v7s-request-dma32-memory-and-improve-debugging.patch mm-add-sys-kernel-slab-cache-cache_dma32.patch
On Tue 19-03-19 11:37:51, Andrew Morton wrote:
From: Nicolas Boichat drinkcat@chromium.org Subject: mm: add /sys/kernel/slab/cache/cache_dma32
A previous patch in this series adds support for SLAB_CACHE_DMA32 kmem caches. This adds the corresponding /sys/kernel/slab/cache/cache_dma32 entries, and fixes slabinfo tool.
I believe I have asked and didn't get a satisfactory answer before IIRC. Who is going to consume this information?
On Wed, Mar 20, 2019 at 3:18 AM Michal Hocko mhocko@kernel.org wrote:
On Tue 19-03-19 11:37:51, Andrew Morton wrote:
From: Nicolas Boichat drinkcat@chromium.org Subject: mm: add /sys/kernel/slab/cache/cache_dma32
A previous patch in this series adds support for SLAB_CACHE_DMA32 kmem caches. This adds the corresponding /sys/kernel/slab/cache/cache_dma32 entries, and fixes slabinfo tool.
I believe I have asked and didn't get a satisfactory answer before IIRC. Who is going to consume this information?
No answer from me, but as a reminder, I added this note on the patch (https://patchwork.kernel.org/patch/10720491/): """ There were different opinions on whether this sysfs entry should be added, so I'll leave it up to the mm/slub maintainers to decide whether they want to pick this up, or drop it. """
-- Michal Hocko SUSE Labs
On Wed 20-03-19 00:37:33, Cristopher Lameter wrote:
On Tue, 19 Mar 2019, Michal Hocko wrote:
I believe I have asked and didn't get a satisfactory answer before IIRC. Who is going to consume this information?
The slabinfo tool consumes this information.
Slabinfo just prints that information without any additional logic AFAICS. So this doesn't look like a usecase to add an API to maintain for ever.
Or is anybody using slabinfo to use this information for anything useful?
On Wed 20-03-19 08:17:52, Nicolas Boichat wrote:
On Wed, Mar 20, 2019 at 3:18 AM Michal Hocko mhocko@kernel.org wrote:
On Tue 19-03-19 11:37:51, Andrew Morton wrote:
From: Nicolas Boichat drinkcat@chromium.org Subject: mm: add /sys/kernel/slab/cache/cache_dma32
A previous patch in this series adds support for SLAB_CACHE_DMA32 kmem caches. This adds the corresponding /sys/kernel/slab/cache/cache_dma32 entries, and fixes slabinfo tool.
I believe I have asked and didn't get a satisfactory answer before IIRC. Who is going to consume this information?
No answer from me, but as a reminder, I added this note on the patch (https://patchwork.kernel.org/patch/10720491/): """ There were different opinions on whether this sysfs entry should be added, so I'll leave it up to the mm/slub maintainers to decide whether they want to pick this up, or drop it. """
We have a terrible track rescord of exporting data to userspace that kick back much later. So I am really convinced that adding new user visible data should be justified by a useful usecase. Exporting just because we can is a terrible justification if you ask me.
This patch is presently in limbo. Should we just drop it?
From: Nicolas Boichat drinkcat@chromium.org Subject: mm: add /sys/kernel/slab/cache/cache_dma32
The patch "mm: add support for kmem caches in DMA32 zone" added support for SLAB_CACHE_DMA32 kmem caches. This patch adds the corresponding /sys/kernel/slab/cache/cache_dma32 entries, and updates the slabinfo tool.
Link: http://lkml.kernel.org/r/20181210011504.122604-4-drinkcat@chromium.org Signed-off-by: Nicolas Boichat drinkcat@chromium.org Cc: Christoph Hellwig hch@infradead.org Cc: Christoph Lameter cl@linux.com Cc: David Rientjes rientjes@google.com Cc: Hsin-Yi Wang hsinyi@chromium.org Cc: Huaisheng Ye yehs1@lenovo.com Cc: Joerg Roedel joro@8bytes.org Cc: Joonsoo Kim iamjoonsoo.kim@lge.com Cc: Matthew Wilcox willy@infradead.org Cc: Matthias Brugger matthias.bgg@gmail.com Cc: Mel Gorman mgorman@techsingularity.net Cc: Michal Hocko mhocko@suse.com Cc: Mike Rapoport rppt@linux.vnet.ibm.com Cc: Pekka Enberg penberg@kernel.org Cc: Robin Murphy robin.murphy@arm.com Cc: Sasha Levin Alexander.Levin@microsoft.com Cc: Tomasz Figa tfiga@google.com Cc: Vlastimil Babka vbabka@suse.cz Cc: Will Deacon will.deacon@arm.com Cc: Yingjoe Chen yingjoe.chen@mediatek.com Cc: Yong Wu yong.wu@mediatek.com Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton akpm@linux-foundation.org ---
Documentation/ABI/testing/sysfs-kernel-slab | 9 +++++++++ mm/slub.c | 11 +++++++++++ tools/vm/slabinfo.c | 7 ++++++- 3 files changed, 26 insertions(+), 1 deletion(-)
--- a/Documentation/ABI/testing/sysfs-kernel-slab~mm-add-sys-kernel-slab-cache-cache_dma32 +++ a/Documentation/ABI/testing/sysfs-kernel-slab @@ -106,6 +106,15 @@ Description: are from ZONE_DMA. Available when CONFIG_ZONE_DMA is enabled.
+What: /sys/kernel/slab/cache/cache_dma32 +Date: December 2018 +KernelVersion: 4.21 +Contact: Nicolas Boichat drinkcat@chromium.org +Description: + The cache_dma32 file is read-only and specifies whether objects + are from ZONE_DMA32. + Available when CONFIG_ZONE_DMA32 is enabled. + What: /sys/kernel/slab/cache/cpu_slabs Date: May 2007 KernelVersion: 2.6.22 --- a/mm/slub.c~mm-add-sys-kernel-slab-cache-cache_dma32 +++ a/mm/slub.c @@ -5112,6 +5112,14 @@ static ssize_t cache_dma_show(struct kme SLAB_ATTR_RO(cache_dma); #endif
+#ifdef CONFIG_ZONE_DMA32 +static ssize_t cache_dma32_show(struct kmem_cache *s, char *buf) +{ + return sprintf(buf, "%d\n", !!(s->flags & SLAB_CACHE_DMA32)); +} +SLAB_ATTR_RO(cache_dma32); +#endif + static ssize_t usersize_show(struct kmem_cache *s, char *buf) { return sprintf(buf, "%u\n", s->usersize); @@ -5452,6 +5460,9 @@ static struct attribute *slab_attrs[] = #ifdef CONFIG_ZONE_DMA &cache_dma_attr.attr, #endif +#ifdef CONFIG_ZONE_DMA32 + &cache_dma32_attr.attr, +#endif #ifdef CONFIG_NUMA &remote_node_defrag_ratio_attr.attr, #endif --- a/tools/vm/slabinfo.c~mm-add-sys-kernel-slab-cache-cache_dma32 +++ a/tools/vm/slabinfo.c @@ -29,7 +29,7 @@ struct slabinfo { char *name; int alias; int refs; - int aliases, align, cache_dma, cpu_slabs, destroy_by_rcu; + int aliases, align, cache_dma, cache_dma32, cpu_slabs, destroy_by_rcu; unsigned int hwcache_align, object_size, objs_per_slab; unsigned int sanity_checks, slab_size, store_user, trace; int order, poison, reclaim_account, red_zone; @@ -534,6 +534,8 @@ static void report(struct slabinfo *s) printf("** Hardware cacheline aligned\n"); if (s->cache_dma) printf("** Memory is allocated in a special DMA zone\n"); + if (s->cache_dma32) + printf("** Memory is allocated in a special DMA32 zone\n"); if (s->destroy_by_rcu) printf("** Slabs are destroyed via RCU\n"); if (s->reclaim_account) @@ -602,6 +604,8 @@ static void slabcache(struct slabinfo *s *p++ = '*'; if (s->cache_dma) *p++ = 'd'; + if (s->cache_dma32) + *p++ = 'D'; if (s->hwcache_align) *p++ = 'A'; if (s->poison) @@ -1208,6 +1212,7 @@ static void read_slab_dir(void) slab->aliases = get_obj("aliases"); slab->align = get_obj("align"); slab->cache_dma = get_obj("cache_dma"); + slab->cache_dma32 = get_obj("cache_dma32"); slab->cpu_slabs = get_obj("cpu_slabs"); slab->destroy_by_rcu = get_obj("destroy_by_rcu"); slab->hwcache_align = get_obj("hwcache_align"); _
On Thu 25-04-19 21:46:15, Andrew Morton wrote:
This patch is presently in limbo. Should we just drop it?
There was no strong justification for it except "we alredy do export dma cache so why not dma32". Christopher was arguing that slabinfo (in tree tool) is going to use it but that merely prints it without any additional considerations. So I would just drop it until there is a real use case (aka somebody is going to use it for something _useful_).
linux-stable-mirror@lists.linaro.org
-
akpm＠linux-foundation.org -
Andrew Morton
-
Christopher Lameter -
Michal Hocko -
Nicolas Boichat