2010-05-17 22:18:00 +00:00
|
|
|
/*****************************************************************************\
|
|
|
|
* Copyright (C) 2007-2010 Lawrence Livermore National Security, LLC.
|
|
|
|
* Copyright (C) 2007 The Regents of the University of California.
|
|
|
|
* Produced at Lawrence Livermore National Laboratory (cf, DISCLAIMER).
|
|
|
|
* Written by Brian Behlendorf <behlendorf1@llnl.gov>.
|
2008-05-26 04:38:26 +00:00
|
|
|
* UCRL-CODE-235197
|
|
|
|
*
|
2010-05-17 22:18:00 +00:00
|
|
|
* This file is part of the SPL, Solaris Porting Layer.
|
2013-03-05 01:26:55 +00:00
|
|
|
* For details, see <http://zfsonlinux.org/>.
|
2010-05-17 22:18:00 +00:00
|
|
|
*
|
|
|
|
* The SPL is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
* Free Software Foundation; either version 2 of the License, or (at your
|
|
|
|
* option) any later version.
|
2008-05-26 04:38:26 +00:00
|
|
|
*
|
2010-05-17 22:18:00 +00:00
|
|
|
* The SPL is distributed in the hope that it will be useful, but WITHOUT
|
2008-05-26 04:38:26 +00:00
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
|
|
|
* for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2010-05-17 22:18:00 +00:00
|
|
|
* with the SPL. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
\*****************************************************************************/
|
2008-05-26 04:38:26 +00:00
|
|
|
|
2008-02-28 00:52:31 +00:00
|
|
|
#ifndef _SPL_KMEM_H
|
|
|
|
#define _SPL_KMEM_H
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-02-27 19:09:51 +00:00
|
|
|
#include <linux/module.h>
|
2008-02-26 20:36:04 +00:00
|
|
|
#include <linux/slab.h>
|
2008-03-14 19:04:41 +00:00
|
|
|
#include <linux/vmalloc.h>
|
2008-02-26 20:36:04 +00:00
|
|
|
#include <linux/spinlock.h>
|
2008-05-06 20:38:28 +00:00
|
|
|
#include <linux/rwsem.h>
|
|
|
|
#include <linux/hash.h>
|
2012-10-30 17:45:50 +00:00
|
|
|
#include <linux/rbtree.h>
|
2008-05-06 20:38:28 +00:00
|
|
|
#include <linux/ctype.h>
|
2009-12-04 23:54:12 +00:00
|
|
|
#include <asm/atomic.h>
|
2008-06-02 17:28:49 +00:00
|
|
|
#include <sys/types.h>
|
2009-02-04 23:15:41 +00:00
|
|
|
#include <sys/vmsystm.h>
|
2010-06-14 21:18:48 +00:00
|
|
|
#include <sys/kstat.h>
|
2012-12-10 18:53:46 +00:00
|
|
|
#include <sys/taskq.h>
|
2008-11-03 20:34:17 +00:00
|
|
|
|
2008-02-26 20:36:04 +00:00
|
|
|
/*
|
|
|
|
* Memory allocation interfaces
|
|
|
|
*/
|
2011-03-19 20:49:14 +00:00
|
|
|
#define KM_SLEEP GFP_KERNEL /* Can sleep, never fails */
|
|
|
|
#define KM_NOSLEEP GFP_ATOMIC /* Can not sleep, may fail */
|
2012-05-01 13:34:39 +00:00
|
|
|
#define KM_PUSHPAGE (GFP_NOIO | __GFP_HIGH) /* Use reserved memory */
|
2011-03-19 20:49:14 +00:00
|
|
|
#define KM_NODEBUG __GFP_NOWARN /* Suppress warnings */
|
|
|
|
#define KM_FLAGS __GFP_BITS_MASK
|
|
|
|
#define KM_VMFLAGS GFP_LEVEL_MASK
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-08-11 22:13:47 +00:00
|
|
|
/*
|
|
|
|
* Used internally, the kernel does not need to support this flag
|
|
|
|
*/
|
|
|
|
#ifndef __GFP_ZERO
|
2008-11-03 21:06:04 +00:00
|
|
|
# define __GFP_ZERO 0x8000
|
2008-08-11 22:13:47 +00:00
|
|
|
#endif
|
|
|
|
|
2009-11-12 23:11:24 +00:00
|
|
|
/*
|
|
|
|
* __GFP_NOFAIL looks like it will be removed from the kernel perhaps as
|
|
|
|
* early as 2.6.32. To avoid this issue when it occurs in upstream kernels
|
|
|
|
* we retry the allocation here as long as it is not __GFP_WAIT (GFP_ATOMIC).
|
|
|
|
* I would prefer the caller handle the failure case cleanly but we are
|
|
|
|
* trying to emulate Solaris and those are not the Solaris semantics.
|
|
|
|
*/
|
|
|
|
static inline void *
|
|
|
|
kmalloc_nofail(size_t size, gfp_t flags)
|
|
|
|
{
|
|
|
|
void *ptr;
|
|
|
|
|
|
|
|
do {
|
|
|
|
ptr = kmalloc(size, flags);
|
|
|
|
} while (ptr == NULL && (flags & __GFP_WAIT));
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void *
|
|
|
|
kzalloc_nofail(size_t size, gfp_t flags)
|
|
|
|
{
|
|
|
|
void *ptr;
|
|
|
|
|
|
|
|
do {
|
|
|
|
ptr = kzalloc(size, flags);
|
|
|
|
} while (ptr == NULL && (flags & __GFP_WAIT));
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void *
|
|
|
|
kmalloc_node_nofail(size_t size, gfp_t flags, int node)
|
|
|
|
{
|
|
|
|
void *ptr;
|
|
|
|
|
|
|
|
do {
|
|
|
|
ptr = kmalloc_node(size, flags, node);
|
|
|
|
} while (ptr == NULL && (flags & __GFP_WAIT));
|
|
|
|
|
|
|
|
return ptr;
|
2010-07-26 22:47:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void *
|
|
|
|
vmalloc_nofail(size_t size, gfp_t flags)
|
|
|
|
{
|
|
|
|
void *ptr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Retry failed __vmalloc() allocations once every second. The
|
|
|
|
* rational for the delay is that the likely failure modes are:
|
|
|
|
*
|
|
|
|
* 1) The system has completely exhausted memory, in which case
|
|
|
|
* delaying 1 second for the memory reclaim to run is reasonable
|
|
|
|
* to avoid thrashing the system.
|
|
|
|
* 2) The system has memory but has exhausted the small virtual
|
|
|
|
* address space available on 32-bit systems. Retrying the
|
|
|
|
* allocation immediately will only result in spinning on the
|
|
|
|
* virtual address space lock. It is better delay a second and
|
|
|
|
* hope that another process will free some of the address space.
|
|
|
|
* But the bottom line is there is not much we can actually do
|
|
|
|
* since we can never safely return a failure and honor the
|
|
|
|
* Solaris semantics.
|
|
|
|
*/
|
|
|
|
while (1) {
|
|
|
|
ptr = __vmalloc(size, flags | __GFP_HIGHMEM, PAGE_KERNEL);
|
|
|
|
if (unlikely((ptr == NULL) && (flags & __GFP_WAIT))) {
|
|
|
|
set_current_state(TASK_INTERRUPTIBLE);
|
|
|
|
schedule_timeout(HZ);
|
|
|
|
} else {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void *
|
|
|
|
vzalloc_nofail(size_t size, gfp_t flags)
|
|
|
|
{
|
|
|
|
void *ptr;
|
|
|
|
|
|
|
|
ptr = vmalloc_nofail(size, flags);
|
|
|
|
if (ptr)
|
|
|
|
memset(ptr, 0, (size));
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
2009-11-12 23:11:24 +00:00
|
|
|
|
2008-02-26 20:36:04 +00:00
|
|
|
#ifdef DEBUG_KMEM
|
2008-11-03 21:06:04 +00:00
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
/*
|
|
|
|
* Memory accounting functions to be used only when DEBUG_KMEM is set.
|
|
|
|
*/
|
|
|
|
# ifdef HAVE_ATOMIC64_T
|
2008-11-03 21:06:04 +00:00
|
|
|
|
2009-12-04 23:54:12 +00:00
|
|
|
# define kmem_alloc_used_add(size) atomic64_add(size, &kmem_alloc_used)
|
|
|
|
# define kmem_alloc_used_sub(size) atomic64_sub(size, &kmem_alloc_used)
|
|
|
|
# define kmem_alloc_used_read() atomic64_read(&kmem_alloc_used)
|
|
|
|
# define kmem_alloc_used_set(size) atomic64_set(&kmem_alloc_used, size)
|
|
|
|
# define vmem_alloc_used_add(size) atomic64_add(size, &vmem_alloc_used)
|
|
|
|
# define vmem_alloc_used_sub(size) atomic64_sub(size, &vmem_alloc_used)
|
|
|
|
# define vmem_alloc_used_read() atomic64_read(&vmem_alloc_used)
|
|
|
|
# define vmem_alloc_used_set(size) atomic64_set(&vmem_alloc_used, size)
|
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
extern atomic64_t kmem_alloc_used;
|
2009-12-04 23:54:12 +00:00
|
|
|
extern unsigned long long kmem_alloc_max;
|
2010-07-26 22:47:55 +00:00
|
|
|
extern atomic64_t vmem_alloc_used;
|
2009-12-04 23:54:12 +00:00
|
|
|
extern unsigned long long vmem_alloc_max;
|
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
# else /* HAVE_ATOMIC64_T */
|
|
|
|
|
2009-12-04 23:54:12 +00:00
|
|
|
# define kmem_alloc_used_add(size) atomic_add(size, &kmem_alloc_used)
|
|
|
|
# define kmem_alloc_used_sub(size) atomic_sub(size, &kmem_alloc_used)
|
|
|
|
# define kmem_alloc_used_read() atomic_read(&kmem_alloc_used)
|
|
|
|
# define kmem_alloc_used_set(size) atomic_set(&kmem_alloc_used, size)
|
|
|
|
# define vmem_alloc_used_add(size) atomic_add(size, &vmem_alloc_used)
|
|
|
|
# define vmem_alloc_used_sub(size) atomic_sub(size, &vmem_alloc_used)
|
|
|
|
# define vmem_alloc_used_read() atomic_read(&vmem_alloc_used)
|
|
|
|
# define vmem_alloc_used_set(size) atomic_set(&vmem_alloc_used, size)
|
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
extern atomic_t kmem_alloc_used;
|
|
|
|
extern unsigned long long kmem_alloc_max;
|
|
|
|
extern atomic_t vmem_alloc_used;
|
|
|
|
extern unsigned long long vmem_alloc_max;
|
2008-11-03 21:06:04 +00:00
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
# endif /* HAVE_ATOMIC64_T */
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
# ifdef DEBUG_KMEM_TRACKING
|
2010-07-26 22:47:55 +00:00
|
|
|
/*
|
|
|
|
* DEBUG_KMEM && DEBUG_KMEM_TRACKING
|
|
|
|
*
|
|
|
|
* The maximum level of memory debugging. All memory will be accounted
|
|
|
|
* for and each allocation will be explicitly tracked. Any allocation
|
|
|
|
* which is leaked will be reported on module unload and the exact location
|
|
|
|
* where that memory was allocation will be reported. This level of memory
|
|
|
|
* tracking will have a significant impact on performance and should only
|
|
|
|
* be enabled for debugging. This feature may be enabled by passing
|
|
|
|
* --enable-debug-kmem-tracking to configure.
|
|
|
|
*/
|
|
|
|
# define kmem_alloc(sz, fl) kmem_alloc_track((sz), (fl), \
|
|
|
|
__FUNCTION__, __LINE__, 0, 0)
|
|
|
|
# define kmem_zalloc(sz, fl) kmem_alloc_track((sz), (fl)|__GFP_ZERO,\
|
|
|
|
__FUNCTION__, __LINE__, 0, 0)
|
|
|
|
# define kmem_alloc_node(sz, fl, nd) kmem_alloc_track((sz), (fl), \
|
|
|
|
__FUNCTION__, __LINE__, 1, nd)
|
|
|
|
# define kmem_free(ptr, sz) kmem_free_track((ptr), (sz))
|
|
|
|
|
|
|
|
# define vmem_alloc(sz, fl) vmem_alloc_track((sz), (fl), \
|
|
|
|
__FUNCTION__, __LINE__)
|
|
|
|
# define vmem_zalloc(sz, fl) vmem_alloc_track((sz), (fl)|__GFP_ZERO,\
|
|
|
|
__FUNCTION__, __LINE__)
|
|
|
|
# define vmem_free(ptr, sz) vmem_free_track((ptr), (sz))
|
|
|
|
|
|
|
|
extern void *kmem_alloc_track(size_t, int, const char *, int, int, int);
|
2012-06-25 17:22:21 +00:00
|
|
|
extern void kmem_free_track(const void *, size_t);
|
2010-07-26 22:47:55 +00:00
|
|
|
extern void *vmem_alloc_track(size_t, int, const char *, int);
|
2012-06-25 17:22:21 +00:00
|
|
|
extern void vmem_free_track(const void *, size_t);
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
# else /* DEBUG_KMEM_TRACKING */
|
2010-07-26 22:47:55 +00:00
|
|
|
/*
|
|
|
|
* DEBUG_KMEM && !DEBUG_KMEM_TRACKING
|
|
|
|
*
|
|
|
|
* The default build will set DEBUG_KEM. This provides basic memory
|
|
|
|
* accounting with little to no impact on performance. When the module
|
|
|
|
* is unloaded in any memory was leaked the total number of leaked bytes
|
|
|
|
* will be reported on the console. To disable this basic accounting
|
|
|
|
* pass the --disable-debug-kmem option to configure.
|
|
|
|
*/
|
|
|
|
# define kmem_alloc(sz, fl) kmem_alloc_debug((sz), (fl), \
|
|
|
|
__FUNCTION__, __LINE__, 0, 0)
|
|
|
|
# define kmem_zalloc(sz, fl) kmem_alloc_debug((sz), (fl)|__GFP_ZERO,\
|
|
|
|
__FUNCTION__, __LINE__, 0, 0)
|
|
|
|
# define kmem_alloc_node(sz, fl, nd) kmem_alloc_debug((sz), (fl), \
|
|
|
|
__FUNCTION__, __LINE__, 1, nd)
|
|
|
|
# define kmem_free(ptr, sz) kmem_free_debug((ptr), (sz))
|
|
|
|
|
|
|
|
# define vmem_alloc(sz, fl) vmem_alloc_debug((sz), (fl), \
|
|
|
|
__FUNCTION__, __LINE__)
|
|
|
|
# define vmem_zalloc(sz, fl) vmem_alloc_debug((sz), (fl)|__GFP_ZERO,\
|
|
|
|
__FUNCTION__, __LINE__)
|
|
|
|
# define vmem_free(ptr, sz) vmem_free_debug((ptr), (sz))
|
|
|
|
|
|
|
|
extern void *kmem_alloc_debug(size_t, int, const char *, int, int, int);
|
2012-06-25 17:22:21 +00:00
|
|
|
extern void kmem_free_debug(const void *, size_t);
|
2010-07-26 22:47:55 +00:00
|
|
|
extern void *vmem_alloc_debug(size_t, int, const char *, int);
|
2012-06-25 17:22:21 +00:00
|
|
|
extern void vmem_free_debug(const void *, size_t);
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
# endif /* DEBUG_KMEM_TRACKING */
|
2008-05-09 22:53:20 +00:00
|
|
|
#else /* DEBUG_KMEM */
|
2010-07-26 22:47:55 +00:00
|
|
|
/*
|
|
|
|
* !DEBUG_KMEM && !DEBUG_KMEM_TRACKING
|
|
|
|
*
|
|
|
|
* All debugging is disabled. There will be no overhead even for
|
|
|
|
* minimal memory accounting. To enable basic accounting pass the
|
|
|
|
* --enable-debug-kmem option to configure.
|
|
|
|
*/
|
|
|
|
# define kmem_alloc(sz, fl) kmalloc_nofail((sz), (fl))
|
|
|
|
# define kmem_zalloc(sz, fl) kzalloc_nofail((sz), (fl))
|
|
|
|
# define kmem_alloc_node(sz, fl, nd) kmalloc_node_nofail((sz), (fl), (nd))
|
|
|
|
# define kmem_free(ptr, sz) ((void)(sz), kfree(ptr))
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
# define vmem_alloc(sz, fl) vmalloc_nofail((sz), (fl))
|
|
|
|
# define vmem_zalloc(sz, fl) vzalloc_nofail((sz), (fl))
|
|
|
|
# define vmem_free(ptr, sz) ((void)(sz), vfree(ptr))
|
2008-03-14 19:04:41 +00:00
|
|
|
|
2008-02-26 20:36:04 +00:00
|
|
|
#endif /* DEBUG_KMEM */
|
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
extern int kmem_debugging(void);
|
|
|
|
extern char *kmem_vasprintf(const char *fmt, va_list ap);
|
|
|
|
extern char *kmem_asprintf(const char *fmt, ...);
|
|
|
|
extern char *strdup(const char *str);
|
|
|
|
extern void strfree(char *str);
|
|
|
|
|
|
|
|
|
2008-02-26 20:36:04 +00:00
|
|
|
/*
|
2010-07-26 22:47:55 +00:00
|
|
|
* Slab allocation interfaces. The SPL slab differs from the standard
|
|
|
|
* Linux SLAB or SLUB primarily in that each cache may be backed by slabs
|
|
|
|
* allocated from the physical or virtal memory address space. The virtual
|
|
|
|
* slabs allow for good behavior when allocation large objects of identical
|
|
|
|
* size. This slab implementation also supports both constructors and
|
|
|
|
* destructions which the Linux slab does not.
|
2008-02-26 20:36:04 +00:00
|
|
|
*/
|
2009-01-31 04:54:49 +00:00
|
|
|
enum {
|
|
|
|
KMC_BIT_NOTOUCH = 0, /* Don't update ages */
|
|
|
|
KMC_BIT_NODEBUG = 1, /* Default behavior */
|
|
|
|
KMC_BIT_NOMAGAZINE = 2, /* XXX: Unsupported */
|
|
|
|
KMC_BIT_NOHASH = 3, /* XXX: Unsupported */
|
|
|
|
KMC_BIT_QCACHE = 4, /* XXX: Unsupported */
|
|
|
|
KMC_BIT_KMEM = 5, /* Use kmem cache */
|
|
|
|
KMC_BIT_VMEM = 6, /* Use vmem cache */
|
2013-12-08 22:01:45 +00:00
|
|
|
KMC_BIT_SLAB = 7, /* Use Linux slab cache */
|
|
|
|
KMC_BIT_OFFSLAB = 8, /* Objects not on slab */
|
|
|
|
KMC_BIT_NOEMERGENCY = 9, /* Disable emergency objects */
|
2012-10-29 23:51:59 +00:00
|
|
|
KMC_BIT_DEADLOCKED = 14, /* Deadlock detected */
|
Emergency slab objects
This patch is designed to resolve a deadlock which can occur with
__vmalloc() based slabs. The issue is that the Linux kernel does
not honor the flags passed to __vmalloc(). This makes it unsafe
to use in a writeback context. Unfortunately, this is a use case
ZFS depends on for correct operation.
Fixing this issue in the upstream kernel was pursued and patches
are available which resolve the issue.
https://bugs.gentoo.org/show_bug.cgi?id=416685
However, these changes were rejected because upstream felt that
using __vmalloc() in the context of writeback should never be done.
Their solution was for us to rewrite parts of ZFS to accomidate
the Linux VM.
While that is probably the right long term solution, and it is
something we want to pursue, it is not a trivial task and will
likely destabilize the existing code. This work has been planned
for the 0.7.0 release but in the meanwhile we want to improve the
SPL slab implementation to accomidate this expected ZFS usage.
This is accomplished by performing the __vmalloc() asynchronously
in the context of a work queue. This doesn't prevent the posibility
of the worker thread from deadlocking. However, the caller can now
safely block on a wait queue for the slab allocation to complete.
Normally this will occur in a reasonable amount of time and the
caller will be woken up when the new slab is available,. The objects
will then get cached in the per-cpu magazines and everything will
proceed as usual.
However, if the __vmalloc() deadlocks for the reasons described
above, or is just very slow, then the callers on the wait queues
will timeout out. When this rare situation occurs they will attempt
to kmalloc() a single minimally sized object using the GFP_NOIO flags.
This allocation will not deadlock because kmalloc() will honor the
passed flags and the caller will be able to make forward progress.
As long as forward progress can be maintained then even if the
worker thread is deadlocked the critical thread will make progress.
This will eventually allow the deadlocked worker thread to complete
and normal operation will resume.
These emergency allocations will likely be slow since they require
contiguous pages. However, their use should be rare so the impact
is expected to be minimal. If that turns out not to be the case in
practice further optimizations are possible.
One additional concern is if these emergency objects are long lived.
Right now they are simply tracked on a list which must be walked when
an object is freed. Is they accumulate on a system and the list
grows freeing objects will become more expensive. This could be
handled relatively easily by using a hash instead of a list, but that
optimization (if needed) is left for a follow up patch.
Additionally, these emeregency objects could be repacked in to existing
slabs as objects are freed if the kmem_cache_set_move() functionality
was implemented. See issue https://github.com/zfsonlinux/spl/issues/26
for full details. This work would also help reduce ZFS's memory
fragmentation problems.
The /proc/spl/kmem/slab file has had two new columns added at the
end. The 'emerg' column reports the current number of these emergency
objects in use for the cache, and the following 'max' column shows
the historical worst case. These value should give us a good idea
of how often these objects are needed. Based on these values under
real use cases we can tune the default behavior.
Lastly, as a side benefit using a single work queue for the slab
allocations should reduce cpu contention on the global virtual address
space lock. This should manifest itself as reduced cpu usage for
the system.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-08-07 23:59:50 +00:00
|
|
|
KMC_BIT_GROWING = 15, /* Growing in progress */
|
2009-01-31 04:54:49 +00:00
|
|
|
KMC_BIT_REAPING = 16, /* Reaping in progress */
|
|
|
|
KMC_BIT_DESTROY = 17, /* Destroy in progress */
|
2011-03-26 07:03:32 +00:00
|
|
|
KMC_BIT_TOTAL = 18, /* Proc handler helper bit */
|
|
|
|
KMC_BIT_ALLOC = 19, /* Proc handler helper bit */
|
|
|
|
KMC_BIT_MAX = 20, /* Proc handler helper bit */
|
2009-01-31 04:54:49 +00:00
|
|
|
};
|
|
|
|
|
2010-08-27 20:28:10 +00:00
|
|
|
/* kmem move callback return values */
|
|
|
|
typedef enum kmem_cbrc {
|
|
|
|
KMEM_CBRC_YES = 0, /* Object moved */
|
|
|
|
KMEM_CBRC_NO = 1, /* Object not moved */
|
|
|
|
KMEM_CBRC_LATER = 2, /* Object not moved, try again later */
|
|
|
|
KMEM_CBRC_DONT_NEED = 3, /* Neither object is needed */
|
|
|
|
KMEM_CBRC_DONT_KNOW = 4, /* Object unknown */
|
|
|
|
} kmem_cbrc_t;
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
#define KMC_NOTOUCH (1 << KMC_BIT_NOTOUCH)
|
|
|
|
#define KMC_NODEBUG (1 << KMC_BIT_NODEBUG)
|
|
|
|
#define KMC_NOMAGAZINE (1 << KMC_BIT_NOMAGAZINE)
|
|
|
|
#define KMC_NOHASH (1 << KMC_BIT_NOHASH)
|
|
|
|
#define KMC_QCACHE (1 << KMC_BIT_QCACHE)
|
|
|
|
#define KMC_KMEM (1 << KMC_BIT_KMEM)
|
|
|
|
#define KMC_VMEM (1 << KMC_BIT_VMEM)
|
2013-12-08 22:01:45 +00:00
|
|
|
#define KMC_SLAB (1 << KMC_BIT_SLAB)
|
2009-01-31 04:54:49 +00:00
|
|
|
#define KMC_OFFSLAB (1 << KMC_BIT_OFFSLAB)
|
2012-09-07 21:24:17 +00:00
|
|
|
#define KMC_NOEMERGENCY (1 << KMC_BIT_NOEMERGENCY)
|
2012-10-29 23:51:59 +00:00
|
|
|
#define KMC_DEADLOCKED (1 << KMC_BIT_DEADLOCKED)
|
Emergency slab objects
This patch is designed to resolve a deadlock which can occur with
__vmalloc() based slabs. The issue is that the Linux kernel does
not honor the flags passed to __vmalloc(). This makes it unsafe
to use in a writeback context. Unfortunately, this is a use case
ZFS depends on for correct operation.
Fixing this issue in the upstream kernel was pursued and patches
are available which resolve the issue.
https://bugs.gentoo.org/show_bug.cgi?id=416685
However, these changes were rejected because upstream felt that
using __vmalloc() in the context of writeback should never be done.
Their solution was for us to rewrite parts of ZFS to accomidate
the Linux VM.
While that is probably the right long term solution, and it is
something we want to pursue, it is not a trivial task and will
likely destabilize the existing code. This work has been planned
for the 0.7.0 release but in the meanwhile we want to improve the
SPL slab implementation to accomidate this expected ZFS usage.
This is accomplished by performing the __vmalloc() asynchronously
in the context of a work queue. This doesn't prevent the posibility
of the worker thread from deadlocking. However, the caller can now
safely block on a wait queue for the slab allocation to complete.
Normally this will occur in a reasonable amount of time and the
caller will be woken up when the new slab is available,. The objects
will then get cached in the per-cpu magazines and everything will
proceed as usual.
However, if the __vmalloc() deadlocks for the reasons described
above, or is just very slow, then the callers on the wait queues
will timeout out. When this rare situation occurs they will attempt
to kmalloc() a single minimally sized object using the GFP_NOIO flags.
This allocation will not deadlock because kmalloc() will honor the
passed flags and the caller will be able to make forward progress.
As long as forward progress can be maintained then even if the
worker thread is deadlocked the critical thread will make progress.
This will eventually allow the deadlocked worker thread to complete
and normal operation will resume.
These emergency allocations will likely be slow since they require
contiguous pages. However, their use should be rare so the impact
is expected to be minimal. If that turns out not to be the case in
practice further optimizations are possible.
One additional concern is if these emergency objects are long lived.
Right now they are simply tracked on a list which must be walked when
an object is freed. Is they accumulate on a system and the list
grows freeing objects will become more expensive. This could be
handled relatively easily by using a hash instead of a list, but that
optimization (if needed) is left for a follow up patch.
Additionally, these emeregency objects could be repacked in to existing
slabs as objects are freed if the kmem_cache_set_move() functionality
was implemented. See issue https://github.com/zfsonlinux/spl/issues/26
for full details. This work would also help reduce ZFS's memory
fragmentation problems.
The /proc/spl/kmem/slab file has had two new columns added at the
end. The 'emerg' column reports the current number of these emergency
objects in use for the cache, and the following 'max' column shows
the historical worst case. These value should give us a good idea
of how often these objects are needed. Based on these values under
real use cases we can tune the default behavior.
Lastly, as a side benefit using a single work queue for the slab
allocations should reduce cpu contention on the global virtual address
space lock. This should manifest itself as reduced cpu usage for
the system.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-08-07 23:59:50 +00:00
|
|
|
#define KMC_GROWING (1 << KMC_BIT_GROWING)
|
2009-01-31 04:54:49 +00:00
|
|
|
#define KMC_REAPING (1 << KMC_BIT_REAPING)
|
|
|
|
#define KMC_DESTROY (1 << KMC_BIT_DESTROY)
|
2011-03-26 07:03:32 +00:00
|
|
|
#define KMC_TOTAL (1 << KMC_BIT_TOTAL)
|
|
|
|
#define KMC_ALLOC (1 << KMC_BIT_ALLOC)
|
|
|
|
#define KMC_MAX (1 << KMC_BIT_MAX)
|
2009-01-31 04:54:49 +00:00
|
|
|
|
2013-01-18 23:44:27 +00:00
|
|
|
#define KMC_REAP_CHUNK INT_MAX
|
|
|
|
#define KMC_DEFAULT_SEEKS 1
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2013-01-18 23:44:27 +00:00
|
|
|
#define KMC_EXPIRE_AGE 0x1 /* Due to age */
|
|
|
|
#define KMC_EXPIRE_MEM 0x2 /* Due to low memory */
|
|
|
|
|
2014-05-16 16:29:21 +00:00
|
|
|
#define KMC_RECLAIM_ONCE 0x1 /* Force a single shrinker pass */
|
|
|
|
|
2013-01-18 23:44:27 +00:00
|
|
|
extern unsigned int spl_kmem_cache_expire;
|
2008-06-27 21:40:11 +00:00
|
|
|
extern struct list_head spl_kmem_cache_list;
|
|
|
|
extern struct rw_semaphore spl_kmem_cache_sem;
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
#define SKM_MAGIC 0x2e2e2e2e
|
2008-06-13 23:41:06 +00:00
|
|
|
#define SKO_MAGIC 0x20202020
|
|
|
|
#define SKS_MAGIC 0x22222222
|
|
|
|
#define SKC_MAGIC 0x2c2c2c2c
|
|
|
|
|
2009-02-12 21:32:10 +00:00
|
|
|
#define SPL_KMEM_CACHE_DELAY 15 /* Minimum slab release age */
|
|
|
|
#define SPL_KMEM_CACHE_REAP 0 /* Default reap everything */
|
2011-03-30 05:38:53 +00:00
|
|
|
#define SPL_KMEM_CACHE_OBJ_PER_SLAB 16 /* Target objects per slab */
|
2014-11-03 21:50:39 +00:00
|
|
|
#define SPL_KMEM_CACHE_OBJ_PER_SLAB_MIN 1 /* Minimum objects per slab */
|
2009-01-31 04:54:49 +00:00
|
|
|
#define SPL_KMEM_CACHE_ALIGN 8 /* Default object alignment */
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2010-08-27 20:28:10 +00:00
|
|
|
#define POINTER_IS_VALID(p) 0 /* Unimplemented */
|
|
|
|
#define POINTER_INVALIDATE(pp) /* Unimplemented */
|
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
typedef int (*spl_kmem_ctor_t)(void *, void *, int);
|
|
|
|
typedef void (*spl_kmem_dtor_t)(void *, void *);
|
|
|
|
typedef void (*spl_kmem_reclaim_t)(void *);
|
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
typedef struct spl_kmem_magazine {
|
2009-02-17 23:52:18 +00:00
|
|
|
uint32_t skm_magic; /* Sanity magic */
|
2008-06-25 20:57:45 +00:00
|
|
|
uint32_t skm_avail; /* Available objects */
|
|
|
|
uint32_t skm_size; /* Magazine size */
|
|
|
|
uint32_t skm_refill; /* Batch refill size */
|
2009-02-17 23:52:18 +00:00
|
|
|
struct spl_kmem_cache *skm_cache; /* Owned by cache */
|
2008-06-25 20:57:45 +00:00
|
|
|
unsigned long skm_age; /* Last cache access */
|
2012-08-23 21:00:58 +00:00
|
|
|
unsigned int skm_cpu; /* Owned by cpu */
|
2008-06-25 20:57:45 +00:00
|
|
|
void *skm_objs[0]; /* Object pointers */
|
|
|
|
} spl_kmem_magazine_t;
|
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
typedef struct spl_kmem_obj {
|
|
|
|
uint32_t sko_magic; /* Sanity magic */
|
|
|
|
void *sko_addr; /* Buffer address */
|
|
|
|
struct spl_kmem_slab *sko_slab; /* Owned by slab */
|
|
|
|
struct list_head sko_list; /* Free object list linkage */
|
|
|
|
} spl_kmem_obj_t;
|
|
|
|
|
|
|
|
typedef struct spl_kmem_slab {
|
|
|
|
uint32_t sks_magic; /* Sanity magic */
|
|
|
|
uint32_t sks_objs; /* Objects per slab */
|
|
|
|
struct spl_kmem_cache *sks_cache; /* Owned by cache */
|
|
|
|
struct list_head sks_list; /* Slab list linkage */
|
|
|
|
struct list_head sks_free_list; /* Free object list */
|
|
|
|
unsigned long sks_age; /* Last modify jiffie */
|
2008-06-25 20:57:45 +00:00
|
|
|
uint32_t sks_ref; /* Ref count used objects */
|
2008-06-13 23:41:06 +00:00
|
|
|
} spl_kmem_slab_t;
|
|
|
|
|
Emergency slab objects
This patch is designed to resolve a deadlock which can occur with
__vmalloc() based slabs. The issue is that the Linux kernel does
not honor the flags passed to __vmalloc(). This makes it unsafe
to use in a writeback context. Unfortunately, this is a use case
ZFS depends on for correct operation.
Fixing this issue in the upstream kernel was pursued and patches
are available which resolve the issue.
https://bugs.gentoo.org/show_bug.cgi?id=416685
However, these changes were rejected because upstream felt that
using __vmalloc() in the context of writeback should never be done.
Their solution was for us to rewrite parts of ZFS to accomidate
the Linux VM.
While that is probably the right long term solution, and it is
something we want to pursue, it is not a trivial task and will
likely destabilize the existing code. This work has been planned
for the 0.7.0 release but in the meanwhile we want to improve the
SPL slab implementation to accomidate this expected ZFS usage.
This is accomplished by performing the __vmalloc() asynchronously
in the context of a work queue. This doesn't prevent the posibility
of the worker thread from deadlocking. However, the caller can now
safely block on a wait queue for the slab allocation to complete.
Normally this will occur in a reasonable amount of time and the
caller will be woken up when the new slab is available,. The objects
will then get cached in the per-cpu magazines and everything will
proceed as usual.
However, if the __vmalloc() deadlocks for the reasons described
above, or is just very slow, then the callers on the wait queues
will timeout out. When this rare situation occurs they will attempt
to kmalloc() a single minimally sized object using the GFP_NOIO flags.
This allocation will not deadlock because kmalloc() will honor the
passed flags and the caller will be able to make forward progress.
As long as forward progress can be maintained then even if the
worker thread is deadlocked the critical thread will make progress.
This will eventually allow the deadlocked worker thread to complete
and normal operation will resume.
These emergency allocations will likely be slow since they require
contiguous pages. However, their use should be rare so the impact
is expected to be minimal. If that turns out not to be the case in
practice further optimizations are possible.
One additional concern is if these emergency objects are long lived.
Right now they are simply tracked on a list which must be walked when
an object is freed. Is they accumulate on a system and the list
grows freeing objects will become more expensive. This could be
handled relatively easily by using a hash instead of a list, but that
optimization (if needed) is left for a follow up patch.
Additionally, these emeregency objects could be repacked in to existing
slabs as objects are freed if the kmem_cache_set_move() functionality
was implemented. See issue https://github.com/zfsonlinux/spl/issues/26
for full details. This work would also help reduce ZFS's memory
fragmentation problems.
The /proc/spl/kmem/slab file has had two new columns added at the
end. The 'emerg' column reports the current number of these emergency
objects in use for the cache, and the following 'max' column shows
the historical worst case. These value should give us a good idea
of how often these objects are needed. Based on these values under
real use cases we can tune the default behavior.
Lastly, as a side benefit using a single work queue for the slab
allocations should reduce cpu contention on the global virtual address
space lock. This should manifest itself as reduced cpu usage for
the system.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-08-07 23:59:50 +00:00
|
|
|
typedef struct spl_kmem_alloc {
|
|
|
|
struct spl_kmem_cache *ska_cache; /* Owned by cache */
|
|
|
|
int ska_flags; /* Allocation flags */
|
2012-12-10 21:40:03 +00:00
|
|
|
taskq_ent_t ska_tqe; /* Task queue entry */
|
Emergency slab objects
This patch is designed to resolve a deadlock which can occur with
__vmalloc() based slabs. The issue is that the Linux kernel does
not honor the flags passed to __vmalloc(). This makes it unsafe
to use in a writeback context. Unfortunately, this is a use case
ZFS depends on for correct operation.
Fixing this issue in the upstream kernel was pursued and patches
are available which resolve the issue.
https://bugs.gentoo.org/show_bug.cgi?id=416685
However, these changes were rejected because upstream felt that
using __vmalloc() in the context of writeback should never be done.
Their solution was for us to rewrite parts of ZFS to accomidate
the Linux VM.
While that is probably the right long term solution, and it is
something we want to pursue, it is not a trivial task and will
likely destabilize the existing code. This work has been planned
for the 0.7.0 release but in the meanwhile we want to improve the
SPL slab implementation to accomidate this expected ZFS usage.
This is accomplished by performing the __vmalloc() asynchronously
in the context of a work queue. This doesn't prevent the posibility
of the worker thread from deadlocking. However, the caller can now
safely block on a wait queue for the slab allocation to complete.
Normally this will occur in a reasonable amount of time and the
caller will be woken up when the new slab is available,. The objects
will then get cached in the per-cpu magazines and everything will
proceed as usual.
However, if the __vmalloc() deadlocks for the reasons described
above, or is just very slow, then the callers on the wait queues
will timeout out. When this rare situation occurs they will attempt
to kmalloc() a single minimally sized object using the GFP_NOIO flags.
This allocation will not deadlock because kmalloc() will honor the
passed flags and the caller will be able to make forward progress.
As long as forward progress can be maintained then even if the
worker thread is deadlocked the critical thread will make progress.
This will eventually allow the deadlocked worker thread to complete
and normal operation will resume.
These emergency allocations will likely be slow since they require
contiguous pages. However, their use should be rare so the impact
is expected to be minimal. If that turns out not to be the case in
practice further optimizations are possible.
One additional concern is if these emergency objects are long lived.
Right now they are simply tracked on a list which must be walked when
an object is freed. Is they accumulate on a system and the list
grows freeing objects will become more expensive. This could be
handled relatively easily by using a hash instead of a list, but that
optimization (if needed) is left for a follow up patch.
Additionally, these emeregency objects could be repacked in to existing
slabs as objects are freed if the kmem_cache_set_move() functionality
was implemented. See issue https://github.com/zfsonlinux/spl/issues/26
for full details. This work would also help reduce ZFS's memory
fragmentation problems.
The /proc/spl/kmem/slab file has had two new columns added at the
end. The 'emerg' column reports the current number of these emergency
objects in use for the cache, and the following 'max' column shows
the historical worst case. These value should give us a good idea
of how often these objects are needed. Based on these values under
real use cases we can tune the default behavior.
Lastly, as a side benefit using a single work queue for the slab
allocations should reduce cpu contention on the global virtual address
space lock. This should manifest itself as reduced cpu usage for
the system.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-08-07 23:59:50 +00:00
|
|
|
} spl_kmem_alloc_t;
|
|
|
|
|
|
|
|
typedef struct spl_kmem_emergency {
|
2012-10-30 17:45:50 +00:00
|
|
|
struct rb_node ske_node; /* Emergency tree linkage */
|
Emergency slab objects
This patch is designed to resolve a deadlock which can occur with
__vmalloc() based slabs. The issue is that the Linux kernel does
not honor the flags passed to __vmalloc(). This makes it unsafe
to use in a writeback context. Unfortunately, this is a use case
ZFS depends on for correct operation.
Fixing this issue in the upstream kernel was pursued and patches
are available which resolve the issue.
https://bugs.gentoo.org/show_bug.cgi?id=416685
However, these changes were rejected because upstream felt that
using __vmalloc() in the context of writeback should never be done.
Their solution was for us to rewrite parts of ZFS to accomidate
the Linux VM.
While that is probably the right long term solution, and it is
something we want to pursue, it is not a trivial task and will
likely destabilize the existing code. This work has been planned
for the 0.7.0 release but in the meanwhile we want to improve the
SPL slab implementation to accomidate this expected ZFS usage.
This is accomplished by performing the __vmalloc() asynchronously
in the context of a work queue. This doesn't prevent the posibility
of the worker thread from deadlocking. However, the caller can now
safely block on a wait queue for the slab allocation to complete.
Normally this will occur in a reasonable amount of time and the
caller will be woken up when the new slab is available,. The objects
will then get cached in the per-cpu magazines and everything will
proceed as usual.
However, if the __vmalloc() deadlocks for the reasons described
above, or is just very slow, then the callers on the wait queues
will timeout out. When this rare situation occurs they will attempt
to kmalloc() a single minimally sized object using the GFP_NOIO flags.
This allocation will not deadlock because kmalloc() will honor the
passed flags and the caller will be able to make forward progress.
As long as forward progress can be maintained then even if the
worker thread is deadlocked the critical thread will make progress.
This will eventually allow the deadlocked worker thread to complete
and normal operation will resume.
These emergency allocations will likely be slow since they require
contiguous pages. However, their use should be rare so the impact
is expected to be minimal. If that turns out not to be the case in
practice further optimizations are possible.
One additional concern is if these emergency objects are long lived.
Right now they are simply tracked on a list which must be walked when
an object is freed. Is they accumulate on a system and the list
grows freeing objects will become more expensive. This could be
handled relatively easily by using a hash instead of a list, but that
optimization (if needed) is left for a follow up patch.
Additionally, these emeregency objects could be repacked in to existing
slabs as objects are freed if the kmem_cache_set_move() functionality
was implemented. See issue https://github.com/zfsonlinux/spl/issues/26
for full details. This work would also help reduce ZFS's memory
fragmentation problems.
The /proc/spl/kmem/slab file has had two new columns added at the
end. The 'emerg' column reports the current number of these emergency
objects in use for the cache, and the following 'max' column shows
the historical worst case. These value should give us a good idea
of how often these objects are needed. Based on these values under
real use cases we can tune the default behavior.
Lastly, as a side benefit using a single work queue for the slab
allocations should reduce cpu contention on the global virtual address
space lock. This should manifest itself as reduced cpu usage for
the system.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-08-07 23:59:50 +00:00
|
|
|
void *ske_obj; /* Buffer address */
|
|
|
|
} spl_kmem_emergency_t;
|
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
typedef struct spl_kmem_cache {
|
2009-01-31 04:54:49 +00:00
|
|
|
uint32_t skc_magic; /* Sanity magic */
|
|
|
|
uint32_t skc_name_size; /* Name length */
|
|
|
|
char *skc_name; /* Name string */
|
2008-06-25 20:57:45 +00:00
|
|
|
spl_kmem_magazine_t *skc_mag[NR_CPUS]; /* Per-CPU warm cache */
|
|
|
|
uint32_t skc_mag_size; /* Magazine size */
|
|
|
|
uint32_t skc_mag_refill; /* Magazine refill count */
|
2009-01-31 04:54:49 +00:00
|
|
|
spl_kmem_ctor_t skc_ctor; /* Constructor */
|
|
|
|
spl_kmem_dtor_t skc_dtor; /* Destructor */
|
|
|
|
spl_kmem_reclaim_t skc_reclaim; /* Reclaimator */
|
|
|
|
void *skc_private; /* Private data */
|
|
|
|
void *skc_vmp; /* Unused */
|
2013-12-08 22:01:45 +00:00
|
|
|
struct kmem_cache *skc_linux_cache; /* Linux slab cache if used */
|
2009-02-02 23:12:30 +00:00
|
|
|
unsigned long skc_flags; /* Flags */
|
2008-06-13 23:41:06 +00:00
|
|
|
uint32_t skc_obj_size; /* Object size */
|
2009-01-26 17:02:04 +00:00
|
|
|
uint32_t skc_obj_align; /* Object alignment */
|
2008-07-01 03:28:54 +00:00
|
|
|
uint32_t skc_slab_objs; /* Objects per slab */
|
2009-01-31 04:54:49 +00:00
|
|
|
uint32_t skc_slab_size; /* Slab size */
|
|
|
|
uint32_t skc_delay; /* Slab reclaim interval */
|
2009-02-12 21:32:10 +00:00
|
|
|
uint32_t skc_reap; /* Slab reclaim count */
|
2009-01-31 04:54:49 +00:00
|
|
|
atomic_t skc_ref; /* Ref count callers */
|
2012-12-10 18:53:46 +00:00
|
|
|
taskqid_t skc_taskqid; /* Slab reclaim task */
|
2009-01-31 04:54:49 +00:00
|
|
|
struct list_head skc_list; /* List of caches linkage */
|
2008-06-13 23:41:06 +00:00
|
|
|
struct list_head skc_complete_list;/* Completely alloc'ed */
|
|
|
|
struct list_head skc_partial_list; /* Partially alloc'ed */
|
2012-10-30 17:45:50 +00:00
|
|
|
struct rb_root skc_emergency_tree; /* Min sized objects */
|
2008-06-24 17:18:15 +00:00
|
|
|
spinlock_t skc_lock; /* Cache lock */
|
Emergency slab objects
This patch is designed to resolve a deadlock which can occur with
__vmalloc() based slabs. The issue is that the Linux kernel does
not honor the flags passed to __vmalloc(). This makes it unsafe
to use in a writeback context. Unfortunately, this is a use case
ZFS depends on for correct operation.
Fixing this issue in the upstream kernel was pursued and patches
are available which resolve the issue.
https://bugs.gentoo.org/show_bug.cgi?id=416685
However, these changes were rejected because upstream felt that
using __vmalloc() in the context of writeback should never be done.
Their solution was for us to rewrite parts of ZFS to accomidate
the Linux VM.
While that is probably the right long term solution, and it is
something we want to pursue, it is not a trivial task and will
likely destabilize the existing code. This work has been planned
for the 0.7.0 release but in the meanwhile we want to improve the
SPL slab implementation to accomidate this expected ZFS usage.
This is accomplished by performing the __vmalloc() asynchronously
in the context of a work queue. This doesn't prevent the posibility
of the worker thread from deadlocking. However, the caller can now
safely block on a wait queue for the slab allocation to complete.
Normally this will occur in a reasonable amount of time and the
caller will be woken up when the new slab is available,. The objects
will then get cached in the per-cpu magazines and everything will
proceed as usual.
However, if the __vmalloc() deadlocks for the reasons described
above, or is just very slow, then the callers on the wait queues
will timeout out. When this rare situation occurs they will attempt
to kmalloc() a single minimally sized object using the GFP_NOIO flags.
This allocation will not deadlock because kmalloc() will honor the
passed flags and the caller will be able to make forward progress.
As long as forward progress can be maintained then even if the
worker thread is deadlocked the critical thread will make progress.
This will eventually allow the deadlocked worker thread to complete
and normal operation will resume.
These emergency allocations will likely be slow since they require
contiguous pages. However, their use should be rare so the impact
is expected to be minimal. If that turns out not to be the case in
practice further optimizations are possible.
One additional concern is if these emergency objects are long lived.
Right now they are simply tracked on a list which must be walked when
an object is freed. Is they accumulate on a system and the list
grows freeing objects will become more expensive. This could be
handled relatively easily by using a hash instead of a list, but that
optimization (if needed) is left for a follow up patch.
Additionally, these emeregency objects could be repacked in to existing
slabs as objects are freed if the kmem_cache_set_move() functionality
was implemented. See issue https://github.com/zfsonlinux/spl/issues/26
for full details. This work would also help reduce ZFS's memory
fragmentation problems.
The /proc/spl/kmem/slab file has had two new columns added at the
end. The 'emerg' column reports the current number of these emergency
objects in use for the cache, and the following 'max' column shows
the historical worst case. These value should give us a good idea
of how often these objects are needed. Based on these values under
real use cases we can tune the default behavior.
Lastly, as a side benefit using a single work queue for the slab
allocations should reduce cpu contention on the global virtual address
space lock. This should manifest itself as reduced cpu usage for
the system.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-08-07 23:59:50 +00:00
|
|
|
wait_queue_head_t skc_waitq; /* Allocation waiters */
|
2008-06-13 23:41:06 +00:00
|
|
|
uint64_t skc_slab_fail; /* Slab alloc failures */
|
|
|
|
uint64_t skc_slab_create;/* Slab creates */
|
|
|
|
uint64_t skc_slab_destroy;/* Slab destroys */
|
2008-06-24 17:18:15 +00:00
|
|
|
uint64_t skc_slab_total; /* Slab total current */
|
2009-01-31 04:54:49 +00:00
|
|
|
uint64_t skc_slab_alloc; /* Slab alloc current */
|
2008-06-24 17:18:15 +00:00
|
|
|
uint64_t skc_slab_max; /* Slab max historic */
|
|
|
|
uint64_t skc_obj_total; /* Obj total current */
|
|
|
|
uint64_t skc_obj_alloc; /* Obj alloc current */
|
|
|
|
uint64_t skc_obj_max; /* Obj max historic */
|
2012-10-29 23:51:59 +00:00
|
|
|
uint64_t skc_obj_deadlock; /* Obj emergency deadlocks */
|
Emergency slab objects
This patch is designed to resolve a deadlock which can occur with
__vmalloc() based slabs. The issue is that the Linux kernel does
not honor the flags passed to __vmalloc(). This makes it unsafe
to use in a writeback context. Unfortunately, this is a use case
ZFS depends on for correct operation.
Fixing this issue in the upstream kernel was pursued and patches
are available which resolve the issue.
https://bugs.gentoo.org/show_bug.cgi?id=416685
However, these changes were rejected because upstream felt that
using __vmalloc() in the context of writeback should never be done.
Their solution was for us to rewrite parts of ZFS to accomidate
the Linux VM.
While that is probably the right long term solution, and it is
something we want to pursue, it is not a trivial task and will
likely destabilize the existing code. This work has been planned
for the 0.7.0 release but in the meanwhile we want to improve the
SPL slab implementation to accomidate this expected ZFS usage.
This is accomplished by performing the __vmalloc() asynchronously
in the context of a work queue. This doesn't prevent the posibility
of the worker thread from deadlocking. However, the caller can now
safely block on a wait queue for the slab allocation to complete.
Normally this will occur in a reasonable amount of time and the
caller will be woken up when the new slab is available,. The objects
will then get cached in the per-cpu magazines and everything will
proceed as usual.
However, if the __vmalloc() deadlocks for the reasons described
above, or is just very slow, then the callers on the wait queues
will timeout out. When this rare situation occurs they will attempt
to kmalloc() a single minimally sized object using the GFP_NOIO flags.
This allocation will not deadlock because kmalloc() will honor the
passed flags and the caller will be able to make forward progress.
As long as forward progress can be maintained then even if the
worker thread is deadlocked the critical thread will make progress.
This will eventually allow the deadlocked worker thread to complete
and normal operation will resume.
These emergency allocations will likely be slow since they require
contiguous pages. However, their use should be rare so the impact
is expected to be minimal. If that turns out not to be the case in
practice further optimizations are possible.
One additional concern is if these emergency objects are long lived.
Right now they are simply tracked on a list which must be walked when
an object is freed. Is they accumulate on a system and the list
grows freeing objects will become more expensive. This could be
handled relatively easily by using a hash instead of a list, but that
optimization (if needed) is left for a follow up patch.
Additionally, these emeregency objects could be repacked in to existing
slabs as objects are freed if the kmem_cache_set_move() functionality
was implemented. See issue https://github.com/zfsonlinux/spl/issues/26
for full details. This work would also help reduce ZFS's memory
fragmentation problems.
The /proc/spl/kmem/slab file has had two new columns added at the
end. The 'emerg' column reports the current number of these emergency
objects in use for the cache, and the following 'max' column shows
the historical worst case. These value should give us a good idea
of how often these objects are needed. Based on these values under
real use cases we can tune the default behavior.
Lastly, as a side benefit using a single work queue for the slab
allocations should reduce cpu contention on the global virtual address
space lock. This should manifest itself as reduced cpu usage for
the system.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-08-07 23:59:50 +00:00
|
|
|
uint64_t skc_obj_emergency; /* Obj emergency current */
|
|
|
|
uint64_t skc_obj_emergency_max; /* Obj emergency max */
|
2008-06-13 23:41:06 +00:00
|
|
|
} spl_kmem_cache_t;
|
2008-08-05 04:16:09 +00:00
|
|
|
#define kmem_cache_t spl_kmem_cache_t
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2010-08-27 20:28:10 +00:00
|
|
|
extern spl_kmem_cache_t *spl_kmem_cache_create(char *name, size_t size,
|
|
|
|
size_t align, spl_kmem_ctor_t ctor, spl_kmem_dtor_t dtor,
|
|
|
|
spl_kmem_reclaim_t reclaim, void *priv, void *vmp, int flags);
|
2012-08-01 06:00:40 +00:00
|
|
|
extern void spl_kmem_cache_set_move(spl_kmem_cache_t *,
|
2010-08-27 20:28:10 +00:00
|
|
|
kmem_cbrc_t (*)(void *, void *, size_t, void *));
|
2008-06-13 23:41:06 +00:00
|
|
|
extern void spl_kmem_cache_destroy(spl_kmem_cache_t *skc);
|
|
|
|
extern void *spl_kmem_cache_alloc(spl_kmem_cache_t *skc, int flags);
|
|
|
|
extern void spl_kmem_cache_free(spl_kmem_cache_t *skc, void *obj);
|
2012-04-27 22:10:02 +00:00
|
|
|
extern void spl_kmem_cache_reap_now(spl_kmem_cache_t *skc, int count);
|
2008-06-13 23:41:06 +00:00
|
|
|
extern void spl_kmem_reap(void);
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
int spl_kmem_init(void);
|
|
|
|
void spl_kmem_fini(void);
|
2008-03-18 04:56:43 +00:00
|
|
|
|
2008-02-26 20:36:04 +00:00
|
|
|
#define kmem_cache_create(name,size,align,ctor,dtor,rclm,priv,vmp,flags) \
|
2008-06-13 23:41:06 +00:00
|
|
|
spl_kmem_cache_create(name,size,align,ctor,dtor,rclm,priv,vmp,flags)
|
2010-08-27 20:28:10 +00:00
|
|
|
#define kmem_cache_set_move(skc, move) spl_kmem_cache_set_move(skc, move)
|
2008-06-13 23:41:06 +00:00
|
|
|
#define kmem_cache_destroy(skc) spl_kmem_cache_destroy(skc)
|
|
|
|
#define kmem_cache_alloc(skc, flags) spl_kmem_cache_alloc(skc, flags)
|
|
|
|
#define kmem_cache_free(skc, obj) spl_kmem_cache_free(skc, obj)
|
2012-04-27 22:10:02 +00:00
|
|
|
#define kmem_cache_reap_now(skc) \
|
|
|
|
spl_kmem_cache_reap_now(skc, skc->skc_reap)
|
2008-06-13 23:41:06 +00:00
|
|
|
#define kmem_reap() spl_kmem_reap()
|
2008-07-01 03:28:54 +00:00
|
|
|
#define kmem_virt(ptr) (((ptr) >= (void *)VMALLOC_START) && \
|
|
|
|
((ptr) < (void *)VMALLOC_END))
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2013-12-08 22:01:45 +00:00
|
|
|
/*
|
|
|
|
* Allow custom slab allocation flags to be set for KMC_SLAB based caches.
|
|
|
|
* One use for this function is to ensure the __GFP_COMP flag is part of
|
|
|
|
* the default allocation mask which ensures higher order allocations are
|
|
|
|
* properly refcounted. This flag was added to the default ->allocflags
|
|
|
|
* as of Linux 3.11.
|
|
|
|
*/
|
|
|
|
static inline void
|
|
|
|
kmem_cache_set_allocflags(spl_kmem_cache_t *skc, gfp_t flags)
|
|
|
|
{
|
|
|
|
if (skc->skc_linux_cache == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
#if defined(HAVE_KMEM_CACHE_ALLOCFLAGS)
|
|
|
|
skc->skc_linux_cache->allocflags |= flags;
|
|
|
|
#elif defined(HAVE_KMEM_CACHE_GFPFLAGS)
|
|
|
|
skc->skc_linux_cache->gfpflags |= flags;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2008-02-28 00:52:31 +00:00
|
|
|
#endif /* _SPL_KMEM_H */
|