[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190403042127.18755-1-tobin@kernel.org>
Date: Wed, 3 Apr 2019 15:21:13 +1100
From: "Tobin C. Harding" <tobin@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Tobin C. Harding" <tobin@...nel.org>,
Roman Gushchin <guro@...com>,
Alexander Viro <viro@....linux.org.uk>,
Christoph Hellwig <hch@...radead.org>,
Pekka Enberg <penberg@...helsinki.fi>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Christopher Lameter <cl@...ux.com>,
Matthew Wilcox <willy@...radead.org>,
Miklos Szeredi <mszeredi@...hat.com>,
Andreas Dilger <adilger@...ger.ca>,
Waiman Long <longman@...hat.com>,
Tycho Andersen <tycho@...ho.ws>,
"Theodore Ts'o" <tytso@....edu>, Andi Kleen <ak@...ux.intel.com>,
David Chinner <david@...morbit.com>,
Nick Piggin <npiggin@...il.com>,
Rik van Riel <riel@...hat.com>,
Hugh Dickins <hughd@...gle.com>, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [RFC PATCH v2 00/14] Slab Movable Objects (SMO)
Hi,
Version 2 re-structured to better follow the structure of Chirstoph's
original patchset (linked below). Functions renamed and other suggestions
on v1 from Roman implemented.
This version also adds an attempt at implementing object migration for
the dcache, appropriate filesystem folk CC'd. Please see comments
below in 'dcache' section.
Applies on top of Linus' tree (tag: v5.1-rc3).
This is a patch set implementing movable objects within the SLUB
allocator. This is work based on Christopher's patch set:
https://lore.kernel.org/patchwork/project/lkml/list/?series=377335
The original code logic is from that set and implemented by Christopher.
Clean up, refactoring, documentation, and additional features by myself.
Blame for any bugs remaining falls solely with myself. Patches using
Christopher's code use the Co-developed-by tag but do not currently have
his SOB tag.
The core of the implementation is now contained within the first 4
patches (primarily patch #4).
Patches 7,8,10 add test code including a test modules to play around
with this. With the series applied one can see functionality in
action by using the slabinfo command on the xarray slab cache
slabinfo radix_tree_node -r
The NUMA stuff works as claimed with the radix_tree_node slab cache.
dcache
------
The dcache patches are my best effort on top of Christoph's original
work. The dcache has changed a lot since then (2009). FTR one month
ago was the first time I have ever opened fs/dcache.c.
I have been playing with this for at least two weeks without any
functional changes to the dcache patches - I do not think me playing
with it more is going to improve my understanding of the dcache so I am
asking for help here. I've been testing in Qemu (both using ramdisk
filesystem and a disk image filesystem) as well as on bare metal.
Shrinking the dcache with:
slabinfo dentry -s
produces _more_ partial slabs than before and repeated calls continue to
increase the number of partial slabs. Although the initial calls do
decrease the total number of cached objects. I cannot explain this.
During development I added a bunch of printks and the majority of dentry
slab objects are skipped during the isolation function due to the
following check from d_isolate():
if (dentry->d_inode &&
!mapping_cap_writeback_dirty(dentry->d_inode->i_mapping))
...
/* skip object*/
I cannot explain the large number of dentry objects skipped by this
clause.
Any suggestions no matter how wild very much appreciated. Tips on files
I should study or anything else I could do to better understand what is
needed to understand to work with this. So far I have been primarily
trying to grok the VFS and the dcache in particular via:
fs/dcache.c
include/linux/fs.h
include/linux/dcache.h
Documentation/filesystems/vfs.txt
I also tried using the cache shrinkers
echo 2 > /proc/sys/vm/drop_caches
Then shrinking the dentry slab cache. This resulted in a bunch of
things disappearing e.g. sysfs gets unmounted, /home directory contents
disappear. Again, I cannot explain this. Should this be doable if this
series was implemented correctly?
Thanks for taking the time to look at this.
Tobin.
Tobin C. Harding (14):
slub: Add isolate() and migrate() methods
tools/vm/slabinfo: Add support for -C and -M options
slub: Sort slab cache list
slub: Slab defrag core
tools/vm/slabinfo: Add remote node defrag ratio output
tools/vm/slabinfo: Add defrag_used_ratio output
tools/testing/slab: Add object migration test module
tools/testing/slab: Add object migration test suite
xarray: Implement migration function for objects
tools/testing/slab: Add XArray movable objects tests
slub: Enable moving objects to/from specific nodes
slub: Enable balancing slabs across nodes
dcache: Provide a dentry constructor
dcache: Implement object migration
Documentation/ABI/testing/sysfs-kernel-slab | 14 +
fs/dcache.c | 124 ++-
include/linux/slab.h | 71 ++
include/linux/slub_def.h | 10 +
lib/radix-tree.c | 13 +
lib/xarray.c | 46 ++
mm/Kconfig | 7 +
mm/slab_common.c | 2 +-
mm/slub.c | 819 ++++++++++++++++++--
tools/testing/slab/Makefile | 10 +
tools/testing/slab/slub_defrag.c | 567 ++++++++++++++
tools/testing/slab/slub_defrag.py | 451 +++++++++++
tools/testing/slab/slub_defrag_xarray.c | 211 +++++
tools/vm/slabinfo.c | 51 +-
14 files changed, 2303 insertions(+), 93 deletions(-)
create mode 100644 tools/testing/slab/Makefile
create mode 100644 tools/testing/slab/slub_defrag.c
create mode 100755 tools/testing/slab/slub_defrag.py
create mode 100644 tools/testing/slab/slub_defrag_xarray.c
--
2.21.0
Powered by blists - more mailing lists