2010-05-18 02:18:00 +04: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 08:38:26 +04:00
|
|
|
* UCRL-CODE-235197
|
|
|
|
*
|
2010-05-18 02:18:00 +04:00
|
|
|
* This file is part of the SPL, Solaris Porting Layer.
|
2013-03-05 05:26:55 +04:00
|
|
|
* For details, see <http://zfsonlinux.org/>.
|
2008-05-26 08:38:26 +04:00
|
|
|
*
|
2010-05-18 02:18:00 +04: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.
|
|
|
|
*
|
|
|
|
* The SPL is distributed in the hope that it will be useful, but WITHOUT
|
2008-05-26 08:38:26 +04: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-18 02:18:00 +04:00
|
|
|
* with the SPL. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*****************************************************************************
|
|
|
|
* Solaris Porting Layer (SPL) Kmem Implementation.
|
|
|
|
\*****************************************************************************/
|
2008-05-26 08:38:26 +04:00
|
|
|
|
2008-03-01 03:45:59 +03:00
|
|
|
#include <sys/kmem.h>
|
2010-07-20 01:16:05 +04:00
|
|
|
#include <spl-debug.h>
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
#ifdef SS_DEBUG_SUBSYS
|
|
|
|
#undef SS_DEBUG_SUBSYS
|
2008-04-21 21:29:47 +04:00
|
|
|
#endif
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
#define SS_DEBUG_SUBSYS SS_KMEM
|
2008-04-21 21:29:47 +04:00
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
/*
|
|
|
|
* Within the scope of spl-kmem.c file the kmem_cache_* definitions
|
|
|
|
* are removed to allow access to the real Linux slab allocator.
|
|
|
|
*/
|
|
|
|
#undef kmem_cache_destroy
|
|
|
|
#undef kmem_cache_create
|
|
|
|
#undef kmem_cache_alloc
|
|
|
|
#undef kmem_cache_free
|
|
|
|
|
|
|
|
|
2013-01-19 03:44:27 +04:00
|
|
|
/*
|
|
|
|
* Cache expiration was implemented because it was part of the default Solaris
|
|
|
|
* kmem_cache behavior. The idea is that per-cpu objects which haven't been
|
|
|
|
* accessed in several seconds should be returned to the cache. On the other
|
|
|
|
* hand Linux slabs never move objects back to the slabs unless there is
|
2013-08-05 03:48:24 +04:00
|
|
|
* memory pressure on the system. By default the Linux method is enabled
|
|
|
|
* because it has been shown to improve responsiveness on low memory systems.
|
|
|
|
* This policy may be changed by setting KMC_EXPIRE_AGE or KMC_EXPIRE_MEM.
|
2013-01-19 03:44:27 +04:00
|
|
|
*/
|
2013-08-05 03:48:24 +04:00
|
|
|
unsigned int spl_kmem_cache_expire = KMC_EXPIRE_MEM;
|
2013-01-19 03:44:27 +04:00
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_expire);
|
|
|
|
module_param(spl_kmem_cache_expire, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(spl_kmem_cache_expire, "By age (0x1) or low memory (0x2)");
|
|
|
|
|
2014-05-16 20:29:21 +04:00
|
|
|
/*
|
2014-08-08 03:14:41 +04:00
|
|
|
* The default behavior is to report the number of objects remaining in the
|
|
|
|
* cache. This allows the Linux VM to repeatedly reclaim objects from the
|
|
|
|
* cache when memory is low satisfy other memory allocations. Alternately,
|
|
|
|
* setting this value to KMC_RECLAIM_ONCE limits how aggressively the cache
|
|
|
|
* is reclaimed. This may increase the likelihood of out of memory events.
|
2014-05-16 20:29:21 +04:00
|
|
|
*/
|
2014-10-02 16:40:05 +04:00
|
|
|
unsigned int spl_kmem_cache_reclaim = 0 /* KMC_RECLAIM_ONCE */;
|
2014-05-16 20:29:21 +04:00
|
|
|
module_param(spl_kmem_cache_reclaim, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(spl_kmem_cache_reclaim, "Single reclaim pass (0x1)");
|
|
|
|
|
2014-02-06 14:08:46 +04:00
|
|
|
unsigned int spl_kmem_cache_obj_per_slab = SPL_KMEM_CACHE_OBJ_PER_SLAB;
|
|
|
|
module_param(spl_kmem_cache_obj_per_slab, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(spl_kmem_cache_obj_per_slab, "Number of objects per slab");
|
|
|
|
|
|
|
|
unsigned int spl_kmem_cache_obj_per_slab_min = SPL_KMEM_CACHE_OBJ_PER_SLAB_MIN;
|
|
|
|
module_param(spl_kmem_cache_obj_per_slab_min, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(spl_kmem_cache_obj_per_slab_min,
|
|
|
|
"Minimal number of objects per slab");
|
|
|
|
|
|
|
|
unsigned int spl_kmem_cache_max_size = 32;
|
|
|
|
module_param(spl_kmem_cache_max_size, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(spl_kmem_cache_max_size, "Maximum size of slab in MB");
|
|
|
|
|
2014-08-08 03:23:04 +04:00
|
|
|
/*
|
|
|
|
* For small objects the Linux slab allocator should be used to make the most
|
|
|
|
* efficient use of the memory. However, large objects are not supported by
|
|
|
|
* the Linux slab and therefore the SPL implementation is preferred. A cutoff
|
|
|
|
* of 16K was determined to be optimal for architectures using 4K pages.
|
|
|
|
*/
|
|
|
|
#if PAGE_SIZE == 4096
|
|
|
|
unsigned int spl_kmem_cache_slab_limit = 16384;
|
|
|
|
#else
|
2013-12-09 02:01:45 +04:00
|
|
|
unsigned int spl_kmem_cache_slab_limit = 0;
|
2014-08-08 03:23:04 +04:00
|
|
|
#endif
|
2013-12-09 02:01:45 +04:00
|
|
|
module_param(spl_kmem_cache_slab_limit, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(spl_kmem_cache_slab_limit,
|
|
|
|
"Objects less than N bytes use the Linux slab");
|
|
|
|
|
|
|
|
unsigned int spl_kmem_cache_kmem_limit = (PAGE_SIZE / 4);
|
|
|
|
module_param(spl_kmem_cache_kmem_limit, uint, 0644);
|
|
|
|
MODULE_PARM_DESC(spl_kmem_cache_kmem_limit,
|
|
|
|
"Objects less than N bytes use the kmalloc");
|
|
|
|
|
2009-02-05 02:15:41 +03:00
|
|
|
vmem_t *heap_arena = NULL;
|
|
|
|
EXPORT_SYMBOL(heap_arena);
|
|
|
|
|
|
|
|
vmem_t *zio_alloc_arena = NULL;
|
|
|
|
EXPORT_SYMBOL(zio_alloc_arena);
|
|
|
|
|
|
|
|
vmem_t *zio_arena = NULL;
|
|
|
|
EXPORT_SYMBOL(zio_arena);
|
|
|
|
|
2009-02-05 23:26:34 +03:00
|
|
|
size_t
|
|
|
|
vmem_size(vmem_t *vmp, int typemask)
|
|
|
|
{
|
2014-10-02 02:05:39 +04:00
|
|
|
ASSERT3P(vmp, ==, NULL);
|
|
|
|
ASSERT3S(typemask & VMEM_ALLOC, ==, VMEM_ALLOC);
|
|
|
|
ASSERT3S(typemask & VMEM_FREE, ==, VMEM_FREE);
|
2009-02-26 00:20:40 +03:00
|
|
|
|
2014-10-02 02:05:39 +04:00
|
|
|
return (VMALLOC_TOTAL);
|
2009-02-05 23:26:34 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vmem_size);
|
|
|
|
|
2010-06-12 01:48:18 +04:00
|
|
|
int
|
|
|
|
kmem_debugging(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_debugging);
|
|
|
|
|
2010-06-24 20:41:59 +04:00
|
|
|
char *
|
|
|
|
kmem_vasprintf(const char *fmt, va_list ap)
|
|
|
|
{
|
|
|
|
va_list aq;
|
|
|
|
char *ptr;
|
|
|
|
|
|
|
|
do {
|
2010-07-21 00:51:42 +04:00
|
|
|
va_copy(aq, ap);
|
2010-06-24 20:41:59 +04:00
|
|
|
ptr = kvasprintf(GFP_KERNEL, fmt, aq);
|
2010-07-21 00:51:42 +04:00
|
|
|
va_end(aq);
|
2010-06-24 20:41:59 +04:00
|
|
|
} while (ptr == NULL);
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_vasprintf);
|
|
|
|
|
2010-06-12 01:48:18 +04:00
|
|
|
char *
|
|
|
|
kmem_asprintf(const char *fmt, ...)
|
|
|
|
{
|
2010-06-24 20:41:59 +04:00
|
|
|
va_list ap;
|
2010-06-12 01:48:18 +04:00
|
|
|
char *ptr;
|
|
|
|
|
|
|
|
do {
|
2010-07-21 00:51:42 +04:00
|
|
|
va_start(ap, fmt);
|
2010-06-24 20:41:59 +04:00
|
|
|
ptr = kvasprintf(GFP_KERNEL, fmt, ap);
|
2010-07-21 00:51:42 +04:00
|
|
|
va_end(ap);
|
2010-06-12 01:48:18 +04:00
|
|
|
} while (ptr == NULL);
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_asprintf);
|
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
static char *
|
|
|
|
__strdup(const char *str, int flags)
|
|
|
|
{
|
|
|
|
char *ptr;
|
|
|
|
int n;
|
|
|
|
|
|
|
|
n = strlen(str);
|
|
|
|
ptr = kmalloc_nofail(n + 1, flags);
|
|
|
|
if (ptr)
|
|
|
|
memcpy(ptr, str, n + 1);
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
char *
|
|
|
|
strdup(const char *str)
|
|
|
|
{
|
|
|
|
return __strdup(str, KM_SLEEP);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(strdup);
|
|
|
|
|
|
|
|
void
|
|
|
|
strfree(char *str)
|
|
|
|
{
|
2010-07-31 09:20:58 +04:00
|
|
|
kfree(str);
|
2010-07-27 02:47:55 +04:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(strfree);
|
|
|
|
|
2008-02-26 23:36:04 +03:00
|
|
|
/*
|
2008-06-14 03:41:06 +04:00
|
|
|
* Memory allocation interfaces and debugging for basic kmem_*
|
2009-10-30 23:58:51 +03:00
|
|
|
* and vmem_* style memory allocation. When DEBUG_KMEM is enabled
|
|
|
|
* the SPL will keep track of the total memory allocated, and
|
|
|
|
* report any memory leaked when the module is unloaded.
|
2008-02-26 23:36:04 +03:00
|
|
|
*/
|
|
|
|
#ifdef DEBUG_KMEM
|
2009-12-05 02:54:12 +03:00
|
|
|
|
2008-02-26 23:36:04 +03:00
|
|
|
/* Shim layer memory accounting */
|
2009-12-05 02:54:12 +03:00
|
|
|
# ifdef HAVE_ATOMIC64_T
|
2008-11-03 23:34:17 +03:00
|
|
|
atomic64_t kmem_alloc_used = ATOMIC64_INIT(0);
|
2008-11-04 00:06:04 +03:00
|
|
|
unsigned long long kmem_alloc_max = 0;
|
2008-11-03 23:34:17 +03:00
|
|
|
atomic64_t vmem_alloc_used = ATOMIC64_INIT(0);
|
2008-11-04 00:06:04 +03:00
|
|
|
unsigned long long vmem_alloc_max = 0;
|
2010-07-27 02:47:55 +04:00
|
|
|
# else /* HAVE_ATOMIC64_T */
|
2009-12-05 02:54:12 +03:00
|
|
|
atomic_t kmem_alloc_used = ATOMIC_INIT(0);
|
|
|
|
unsigned long long kmem_alloc_max = 0;
|
|
|
|
atomic_t vmem_alloc_used = ATOMIC_INIT(0);
|
|
|
|
unsigned long long vmem_alloc_max = 0;
|
2010-07-27 02:47:55 +04:00
|
|
|
# endif /* HAVE_ATOMIC64_T */
|
2008-03-14 22:04:41 +03:00
|
|
|
|
2008-06-28 01:40:11 +04:00
|
|
|
EXPORT_SYMBOL(kmem_alloc_used);
|
|
|
|
EXPORT_SYMBOL(kmem_alloc_max);
|
|
|
|
EXPORT_SYMBOL(vmem_alloc_used);
|
|
|
|
EXPORT_SYMBOL(vmem_alloc_max);
|
|
|
|
|
2009-10-30 23:58:51 +03:00
|
|
|
/* When DEBUG_KMEM_TRACKING is enabled not only will total bytes be tracked
|
|
|
|
* but also the location of every alloc and free. When the SPL module is
|
|
|
|
* unloaded a list of all leaked addresses and where they were allocated
|
|
|
|
* will be dumped to the console. Enabling this feature has a significant
|
|
|
|
* impact on performance but it makes finding memory leaks straight forward.
|
|
|
|
*
|
|
|
|
* Not surprisingly with debugging enabled the xmem_locks are very highly
|
|
|
|
* contended particularly on xfree(). If we want to run with this detailed
|
|
|
|
* debugging enabled for anything other than debugging we need to minimize
|
|
|
|
* the contention by moving to a lock per xmem_table entry model.
|
2008-11-04 00:06:04 +03:00
|
|
|
*/
|
2009-10-30 23:58:51 +03:00
|
|
|
# ifdef DEBUG_KMEM_TRACKING
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
# define KMEM_HASH_BITS 10
|
|
|
|
# define KMEM_TABLE_SIZE (1 << KMEM_HASH_BITS)
|
|
|
|
|
|
|
|
# define VMEM_HASH_BITS 10
|
|
|
|
# define VMEM_TABLE_SIZE (1 << VMEM_HASH_BITS)
|
|
|
|
|
|
|
|
typedef struct kmem_debug {
|
|
|
|
struct hlist_node kd_hlist; /* Hash node linkage */
|
|
|
|
struct list_head kd_list; /* List of all allocations */
|
|
|
|
void *kd_addr; /* Allocation pointer */
|
|
|
|
size_t kd_size; /* Allocation size */
|
|
|
|
const char *kd_func; /* Allocation function */
|
|
|
|
int kd_line; /* Allocation line */
|
|
|
|
} kmem_debug_t;
|
|
|
|
|
2008-05-07 00:38:28 +04:00
|
|
|
spinlock_t kmem_lock;
|
|
|
|
struct hlist_head kmem_table[KMEM_TABLE_SIZE];
|
|
|
|
struct list_head kmem_list;
|
|
|
|
|
2008-05-07 22:54:32 +04:00
|
|
|
spinlock_t vmem_lock;
|
|
|
|
struct hlist_head vmem_table[VMEM_TABLE_SIZE];
|
|
|
|
struct list_head vmem_list;
|
|
|
|
|
2008-05-07 00:38:28 +04:00
|
|
|
EXPORT_SYMBOL(kmem_lock);
|
|
|
|
EXPORT_SYMBOL(kmem_table);
|
|
|
|
EXPORT_SYMBOL(kmem_list);
|
|
|
|
|
2008-05-07 22:54:32 +04:00
|
|
|
EXPORT_SYMBOL(vmem_lock);
|
|
|
|
EXPORT_SYMBOL(vmem_table);
|
|
|
|
EXPORT_SYMBOL(vmem_list);
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
static kmem_debug_t *
|
2012-06-25 21:22:21 +04:00
|
|
|
kmem_del_init(spinlock_t *lock, struct hlist_head *table, int bits, const void *addr)
|
2008-11-04 00:06:04 +03:00
|
|
|
{
|
|
|
|
struct hlist_head *head;
|
|
|
|
struct hlist_node *node;
|
|
|
|
struct kmem_debug *p;
|
|
|
|
unsigned long flags;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
spin_lock_irqsave(lock, flags);
|
|
|
|
|
2013-07-03 21:14:35 +04:00
|
|
|
head = &table[hash_ptr((void *)addr, bits)];
|
|
|
|
hlist_for_each(node, head) {
|
|
|
|
p = list_entry(node, struct kmem_debug, kd_hlist);
|
2008-11-04 00:06:04 +03:00
|
|
|
if (p->kd_addr == addr) {
|
|
|
|
hlist_del_init(&p->kd_hlist);
|
|
|
|
list_del_init(&p->kd_list);
|
|
|
|
spin_unlock_irqrestore(lock, flags);
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(lock, flags);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(NULL);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void *
|
|
|
|
kmem_alloc_track(size_t size, int flags, const char *func, int line,
|
|
|
|
int node_alloc, int node)
|
|
|
|
{
|
|
|
|
void *ptr = NULL;
|
|
|
|
kmem_debug_t *dptr;
|
|
|
|
unsigned long irq_flags;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-11-04 00:06:04 +03:00
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
/* Function may be called with KM_NOSLEEP so failure is possible */
|
2009-11-13 02:11:24 +03:00
|
|
|
dptr = (kmem_debug_t *) kmalloc_nofail(sizeof(kmem_debug_t),
|
2008-11-04 00:06:04 +03:00
|
|
|
flags & ~__GFP_ZERO);
|
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
if (unlikely(dptr == NULL)) {
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "debug "
|
2010-06-17 02:57:04 +04:00
|
|
|
"kmem_alloc(%ld, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
sizeof(kmem_debug_t), flags, func, line,
|
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
} else {
|
2010-07-27 02:47:55 +04:00
|
|
|
/*
|
|
|
|
* Marked unlikely because we should never be doing this,
|
|
|
|
* we tolerate to up 2 pages but a single page is best.
|
|
|
|
*/
|
2010-05-21 01:16:59 +04:00
|
|
|
if (unlikely((size > PAGE_SIZE*2) && !(flags & KM_NODEBUG))) {
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "large "
|
2010-06-17 02:57:04 +04:00
|
|
|
"kmem_alloc(%llu, 0x%x) at %s:%d (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-05 02:54:12 +03:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2010-05-20 03:53:13 +04:00
|
|
|
spl_debug_dumpstack(NULL);
|
|
|
|
}
|
2008-11-04 00:06:04 +03:00
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
/*
|
|
|
|
* We use __strdup() below because the string pointed to by
|
2008-11-04 01:02:15 +03:00
|
|
|
* __FUNCTION__ might not be available by the time we want
|
2010-07-27 02:47:55 +04:00
|
|
|
* to print it since the module might have been unloaded.
|
|
|
|
* This can only fail in the KM_NOSLEEP case.
|
|
|
|
*/
|
|
|
|
dptr->kd_func = __strdup(func, flags & ~__GFP_ZERO);
|
2008-11-04 01:02:15 +03:00
|
|
|
if (unlikely(dptr->kd_func == NULL)) {
|
|
|
|
kfree(dptr);
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-07-27 02:47:55 +04:00
|
|
|
"debug __strdup() at %s:%d failed (%lld/%llu)\n",
|
2010-06-17 02:57:04 +04:00
|
|
|
func, line, kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-04 01:02:15 +03:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2008-11-04 00:06:04 +03:00
|
|
|
/* Use the correct allocator */
|
|
|
|
if (node_alloc) {
|
|
|
|
ASSERT(!(flags & __GFP_ZERO));
|
2009-11-13 02:11:24 +03:00
|
|
|
ptr = kmalloc_node_nofail(size, flags, node);
|
2008-11-04 00:06:04 +03:00
|
|
|
} else if (flags & __GFP_ZERO) {
|
2009-11-13 02:11:24 +03:00
|
|
|
ptr = kzalloc_nofail(size, flags & ~__GFP_ZERO);
|
2008-11-04 00:06:04 +03:00
|
|
|
} else {
|
2009-11-13 02:11:24 +03:00
|
|
|
ptr = kmalloc_nofail(size, flags);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (unlikely(ptr == NULL)) {
|
2008-11-04 01:02:15 +03:00
|
|
|
kfree(dptr->kd_func);
|
2008-11-04 00:06:04 +03:00
|
|
|
kfree(dptr);
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "kmem_alloc"
|
2010-06-17 02:57:04 +04:00
|
|
|
"(%llu, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-05 02:54:12 +03:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2009-12-05 02:54:12 +03:00
|
|
|
kmem_alloc_used_add(size);
|
|
|
|
if (unlikely(kmem_alloc_used_read() > kmem_alloc_max))
|
|
|
|
kmem_alloc_max = kmem_alloc_used_read();
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
INIT_HLIST_NODE(&dptr->kd_hlist);
|
|
|
|
INIT_LIST_HEAD(&dptr->kd_list);
|
|
|
|
|
|
|
|
dptr->kd_addr = ptr;
|
|
|
|
dptr->kd_size = size;
|
|
|
|
dptr->kd_line = line;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&kmem_lock, irq_flags);
|
2013-07-03 21:14:35 +04:00
|
|
|
hlist_add_head(&dptr->kd_hlist,
|
2008-11-04 00:06:04 +03:00
|
|
|
&kmem_table[hash_ptr(ptr, KMEM_HASH_BITS)]);
|
|
|
|
list_add_tail(&dptr->kd_list, &kmem_list);
|
|
|
|
spin_unlock_irqrestore(&kmem_lock, irq_flags);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_INFO,
|
2010-06-17 02:57:04 +04:00
|
|
|
"kmem_alloc(%llu, 0x%x) at %s:%d = %p (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line, ptr,
|
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
out:
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(ptr);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_alloc_track);
|
|
|
|
|
|
|
|
void
|
2012-06-25 21:22:21 +04:00
|
|
|
kmem_free_track(const void *ptr, size_t size)
|
2008-11-04 00:06:04 +03:00
|
|
|
{
|
|
|
|
kmem_debug_t *dptr;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
ASSERTF(ptr || size > 0, "ptr: %p, size: %llu", ptr,
|
|
|
|
(unsigned long long) size);
|
|
|
|
|
|
|
|
dptr = kmem_del_init(&kmem_lock, kmem_table, KMEM_HASH_BITS, ptr);
|
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
/* Must exist in hash due to kmem_alloc() */
|
|
|
|
ASSERT(dptr);
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
/* Size must match */
|
|
|
|
ASSERTF(dptr->kd_size == size, "kd_size (%llu) != size (%llu), "
|
|
|
|
"kd_func = %s, kd_line = %d\n", (unsigned long long) dptr->kd_size,
|
|
|
|
(unsigned long long) size, dptr->kd_func, dptr->kd_line);
|
|
|
|
|
2009-12-05 02:54:12 +03:00
|
|
|
kmem_alloc_used_sub(size);
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "kmem_free(%p, %llu) (%lld/%llu)\n", ptr,
|
2009-12-05 02:54:12 +03:00
|
|
|
(unsigned long long) size, kmem_alloc_used_read(),
|
2008-11-04 00:06:04 +03:00
|
|
|
kmem_alloc_max);
|
|
|
|
|
2008-11-04 01:02:15 +03:00
|
|
|
kfree(dptr->kd_func);
|
|
|
|
|
2013-07-03 21:14:35 +04:00
|
|
|
memset((void *)dptr, 0x5a, sizeof(kmem_debug_t));
|
2008-11-04 00:06:04 +03:00
|
|
|
kfree(dptr);
|
|
|
|
|
2013-07-03 21:14:35 +04:00
|
|
|
memset((void *)ptr, 0x5a, size);
|
2008-11-04 00:06:04 +03:00
|
|
|
kfree(ptr);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_free_track);
|
|
|
|
|
|
|
|
void *
|
|
|
|
vmem_alloc_track(size_t size, int flags, const char *func, int line)
|
|
|
|
{
|
|
|
|
void *ptr = NULL;
|
|
|
|
kmem_debug_t *dptr;
|
|
|
|
unsigned long irq_flags;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
ASSERT(flags & KM_SLEEP);
|
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
/* Function may be called with KM_NOSLEEP so failure is possible */
|
2009-12-23 23:57:10 +03:00
|
|
|
dptr = (kmem_debug_t *) kmalloc_nofail(sizeof(kmem_debug_t),
|
|
|
|
flags & ~__GFP_ZERO);
|
2010-07-27 02:47:55 +04:00
|
|
|
if (unlikely(dptr == NULL)) {
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "debug "
|
2010-06-17 02:57:04 +04:00
|
|
|
"vmem_alloc(%ld, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
sizeof(kmem_debug_t), flags, func, line,
|
|
|
|
vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
} else {
|
2010-07-27 02:47:55 +04:00
|
|
|
/*
|
|
|
|
* We use __strdup() below because the string pointed to by
|
2008-11-04 01:02:15 +03:00
|
|
|
* __FUNCTION__ might not be available by the time we want
|
2010-07-27 02:47:55 +04:00
|
|
|
* to print it, since the module might have been unloaded.
|
|
|
|
* This can never fail because we have already asserted
|
|
|
|
* that flags is KM_SLEEP.
|
|
|
|
*/
|
|
|
|
dptr->kd_func = __strdup(func, flags & ~__GFP_ZERO);
|
2008-11-04 01:02:15 +03:00
|
|
|
if (unlikely(dptr->kd_func == NULL)) {
|
|
|
|
kfree(dptr);
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-07-27 02:47:55 +04:00
|
|
|
"debug __strdup() at %s:%d failed (%lld/%llu)\n",
|
2010-06-17 02:57:04 +04:00
|
|
|
func, line, vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-04 01:02:15 +03:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
/* Use the correct allocator */
|
|
|
|
if (flags & __GFP_ZERO) {
|
|
|
|
ptr = vzalloc_nofail(size, flags & ~__GFP_ZERO);
|
|
|
|
} else {
|
|
|
|
ptr = vmalloc_nofail(size, flags);
|
|
|
|
}
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
if (unlikely(ptr == NULL)) {
|
2008-11-04 01:02:15 +03:00
|
|
|
kfree(dptr->kd_func);
|
2008-11-04 00:06:04 +03:00
|
|
|
kfree(dptr);
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "vmem_alloc"
|
2010-06-17 02:57:04 +04:00
|
|
|
"(%llu, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-05 02:54:12 +03:00
|
|
|
vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2009-12-05 02:54:12 +03:00
|
|
|
vmem_alloc_used_add(size);
|
|
|
|
if (unlikely(vmem_alloc_used_read() > vmem_alloc_max))
|
|
|
|
vmem_alloc_max = vmem_alloc_used_read();
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
INIT_HLIST_NODE(&dptr->kd_hlist);
|
|
|
|
INIT_LIST_HEAD(&dptr->kd_list);
|
|
|
|
|
|
|
|
dptr->kd_addr = ptr;
|
|
|
|
dptr->kd_size = size;
|
|
|
|
dptr->kd_line = line;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&vmem_lock, irq_flags);
|
2013-07-03 21:14:35 +04:00
|
|
|
hlist_add_head(&dptr->kd_hlist,
|
2008-11-04 00:06:04 +03:00
|
|
|
&vmem_table[hash_ptr(ptr, VMEM_HASH_BITS)]);
|
|
|
|
list_add_tail(&dptr->kd_list, &vmem_list);
|
|
|
|
spin_unlock_irqrestore(&vmem_lock, irq_flags);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_INFO,
|
2010-06-17 02:57:04 +04:00
|
|
|
"vmem_alloc(%llu, 0x%x) at %s:%d = %p (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
|
|
|
ptr, vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
out:
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(ptr);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vmem_alloc_track);
|
|
|
|
|
|
|
|
void
|
2012-06-25 21:22:21 +04:00
|
|
|
vmem_free_track(const void *ptr, size_t size)
|
2008-11-04 00:06:04 +03:00
|
|
|
{
|
|
|
|
kmem_debug_t *dptr;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
ASSERTF(ptr || size > 0, "ptr: %p, size: %llu", ptr,
|
|
|
|
(unsigned long long) size);
|
|
|
|
|
|
|
|
dptr = kmem_del_init(&vmem_lock, vmem_table, VMEM_HASH_BITS, ptr);
|
2010-07-27 02:47:55 +04:00
|
|
|
|
|
|
|
/* Must exist in hash due to vmem_alloc() */
|
|
|
|
ASSERT(dptr);
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
/* Size must match */
|
|
|
|
ASSERTF(dptr->kd_size == size, "kd_size (%llu) != size (%llu), "
|
|
|
|
"kd_func = %s, kd_line = %d\n", (unsigned long long) dptr->kd_size,
|
|
|
|
(unsigned long long) size, dptr->kd_func, dptr->kd_line);
|
|
|
|
|
2009-12-05 02:54:12 +03:00
|
|
|
vmem_alloc_used_sub(size);
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "vmem_free(%p, %llu) (%lld/%llu)\n", ptr,
|
2009-12-05 02:54:12 +03:00
|
|
|
(unsigned long long) size, vmem_alloc_used_read(),
|
2008-11-04 00:06:04 +03:00
|
|
|
vmem_alloc_max);
|
|
|
|
|
2008-11-04 01:02:15 +03:00
|
|
|
kfree(dptr->kd_func);
|
|
|
|
|
2013-07-03 21:14:35 +04:00
|
|
|
memset((void *)dptr, 0x5a, sizeof(kmem_debug_t));
|
2008-11-04 00:06:04 +03:00
|
|
|
kfree(dptr);
|
|
|
|
|
2013-07-03 21:14:35 +04:00
|
|
|
memset((void *)ptr, 0x5a, size);
|
2008-11-04 00:06:04 +03:00
|
|
|
vfree(ptr);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vmem_free_track);
|
|
|
|
|
|
|
|
# else /* DEBUG_KMEM_TRACKING */
|
|
|
|
|
|
|
|
void *
|
|
|
|
kmem_alloc_debug(size_t size, int flags, const char *func, int line,
|
|
|
|
int node_alloc, int node)
|
|
|
|
{
|
|
|
|
void *ptr;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-11-04 00:06:04 +03:00
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
/*
|
|
|
|
* Marked unlikely because we should never be doing this,
|
|
|
|
* we tolerate to up 2 pages but a single page is best.
|
|
|
|
*/
|
2010-05-21 01:16:59 +04:00
|
|
|
if (unlikely((size > PAGE_SIZE * 2) && !(flags & KM_NODEBUG))) {
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG(SD_CONSOLE | SD_WARNING,
|
2010-07-27 02:47:55 +04:00
|
|
|
"large kmem_alloc(%llu, 0x%x) at %s:%d (%lld/%llu)\n",
|
2010-06-17 02:57:04 +04:00
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-05 02:54:12 +03:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2014-07-17 01:00:57 +04:00
|
|
|
spl_debug_dumpstack(NULL);
|
2010-05-20 03:53:13 +04:00
|
|
|
}
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
/* Use the correct allocator */
|
|
|
|
if (node_alloc) {
|
|
|
|
ASSERT(!(flags & __GFP_ZERO));
|
2009-11-13 02:11:24 +03:00
|
|
|
ptr = kmalloc_node_nofail(size, flags, node);
|
2008-11-04 00:06:04 +03:00
|
|
|
} else if (flags & __GFP_ZERO) {
|
2009-11-13 02:11:24 +03:00
|
|
|
ptr = kzalloc_nofail(size, flags & (~__GFP_ZERO));
|
2008-11-04 00:06:04 +03:00
|
|
|
} else {
|
2009-11-13 02:11:24 +03:00
|
|
|
ptr = kmalloc_nofail(size, flags);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
if (unlikely(ptr == NULL)) {
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-06-17 02:57:04 +04:00
|
|
|
"kmem_alloc(%llu, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-05 02:54:12 +03:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
} else {
|
2009-12-05 02:54:12 +03:00
|
|
|
kmem_alloc_used_add(size);
|
|
|
|
if (unlikely(kmem_alloc_used_read() > kmem_alloc_max))
|
|
|
|
kmem_alloc_max = kmem_alloc_used_read();
|
2008-11-04 00:06:04 +03:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_INFO,
|
2010-06-17 02:57:04 +04:00
|
|
|
"kmem_alloc(%llu, 0x%x) at %s:%d = %p (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line, ptr,
|
2010-07-27 02:47:55 +04:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
2010-07-27 02:47:55 +04:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(ptr);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_alloc_debug);
|
|
|
|
|
|
|
|
void
|
2012-06-25 21:22:21 +04:00
|
|
|
kmem_free_debug(const void *ptr, size_t size)
|
2008-11-04 00:06:04 +03:00
|
|
|
{
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
ASSERTF(ptr || size > 0, "ptr: %p, size: %llu", ptr,
|
|
|
|
(unsigned long long) size);
|
|
|
|
|
2009-12-05 02:54:12 +03:00
|
|
|
kmem_alloc_used_sub(size);
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "kmem_free(%p, %llu) (%lld/%llu)\n", ptr,
|
2009-12-05 02:54:12 +03:00
|
|
|
(unsigned long long) size, kmem_alloc_used_read(),
|
2008-11-04 00:06:04 +03:00
|
|
|
kmem_alloc_max);
|
|
|
|
kfree(ptr);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_free_debug);
|
|
|
|
|
|
|
|
void *
|
|
|
|
vmem_alloc_debug(size_t size, int flags, const char *func, int line)
|
|
|
|
{
|
|
|
|
void *ptr;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
ASSERT(flags & KM_SLEEP);
|
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
/* Use the correct allocator */
|
|
|
|
if (flags & __GFP_ZERO) {
|
|
|
|
ptr = vzalloc_nofail(size, flags & (~__GFP_ZERO));
|
|
|
|
} else {
|
|
|
|
ptr = vmalloc_nofail(size, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (unlikely(ptr == NULL)) {
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-06-17 02:57:04 +04:00
|
|
|
"vmem_alloc(%llu, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-05 02:54:12 +03:00
|
|
|
vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
} else {
|
2009-12-05 02:54:12 +03:00
|
|
|
vmem_alloc_used_add(size);
|
|
|
|
if (unlikely(vmem_alloc_used_read() > vmem_alloc_max))
|
|
|
|
vmem_alloc_max = vmem_alloc_used_read();
|
2008-11-04 00:06:04 +03:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "vmem_alloc(%llu, 0x%x) = %p "
|
2008-11-04 00:06:04 +03:00
|
|
|
"(%lld/%llu)\n", (unsigned long long) size, flags, ptr,
|
2009-12-05 02:54:12 +03:00
|
|
|
vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(ptr);
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vmem_alloc_debug);
|
|
|
|
|
|
|
|
void
|
2012-06-25 21:22:21 +04:00
|
|
|
vmem_free_debug(const void *ptr, size_t size)
|
2008-11-04 00:06:04 +03:00
|
|
|
{
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
ASSERTF(ptr || size > 0, "ptr: %p, size: %llu", ptr,
|
|
|
|
(unsigned long long) size);
|
|
|
|
|
2009-12-05 02:54:12 +03:00
|
|
|
vmem_alloc_used_sub(size);
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "vmem_free(%p, %llu) (%lld/%llu)\n", ptr,
|
2009-12-05 02:54:12 +03:00
|
|
|
(unsigned long long) size, vmem_alloc_used_read(),
|
2008-11-04 00:06:04 +03:00
|
|
|
vmem_alloc_max);
|
|
|
|
vfree(ptr);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-11-04 00:06:04 +03:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vmem_free_debug);
|
|
|
|
|
|
|
|
# endif /* DEBUG_KMEM_TRACKING */
|
|
|
|
#endif /* DEBUG_KMEM */
|
|
|
|
|
2010-07-27 02:47:55 +04:00
|
|
|
/*
|
|
|
|
* Slab allocation interfaces
|
|
|
|
*
|
|
|
|
* While the Linux slab implementation was inspired by the Solaris
|
2011-10-11 21:11:26 +04:00
|
|
|
* implementation I cannot use it to emulate the Solaris APIs. I
|
2010-07-27 02:47:55 +04:00
|
|
|
* require two features which are not provided by the Linux slab.
|
|
|
|
*
|
|
|
|
* 1) Constructors AND destructors. Recent versions of the Linux
|
|
|
|
* kernel have removed support for destructors. This is a deal
|
|
|
|
* breaker for the SPL which contains particularly expensive
|
|
|
|
* initializers for mutex's, condition variables, etc. We also
|
|
|
|
* require a minimal level of cleanup for these data types unlike
|
|
|
|
* many Linux data type which do need to be explicitly destroyed.
|
|
|
|
*
|
|
|
|
* 2) Virtual address space backed slab. Callers of the Solaris slab
|
|
|
|
* expect it to work well for both small are very large allocations.
|
|
|
|
* Because of memory fragmentation the Linux slab which is backed
|
|
|
|
* by kmalloc'ed memory performs very badly when confronted with
|
|
|
|
* large numbers of large allocations. Basing the slab on the
|
2011-10-11 21:11:26 +04:00
|
|
|
* virtual address space removes the need for contiguous pages
|
2010-07-27 02:47:55 +04:00
|
|
|
* and greatly improve performance for large allocations.
|
|
|
|
*
|
|
|
|
* For these reasons, the SPL has its own slab implementation with
|
|
|
|
* the needed features. It is not as highly optimized as either the
|
|
|
|
* Solaris or Linux slabs, but it should get me most of what is
|
|
|
|
* needed until it can be optimized or obsoleted by another approach.
|
|
|
|
*
|
|
|
|
* One serious concern I do have about this method is the relatively
|
|
|
|
* small virtual address space on 32bit arches. This will seriously
|
|
|
|
* constrain the size of the slab caches and their performance.
|
|
|
|
*
|
|
|
|
* XXX: Improve the partial slab list by carefully maintaining a
|
|
|
|
* strict ordering of fullest to emptiest slabs based on
|
2011-10-11 21:11:26 +04:00
|
|
|
* the slab reference count. This guarantees the when freeing
|
2010-07-27 02:47:55 +04:00
|
|
|
* slabs back to the system we need only linearly traverse the
|
|
|
|
* last N slabs in the list to discover all the freeable slabs.
|
|
|
|
*
|
|
|
|
* XXX: NUMA awareness for optionally allocating memory close to a
|
2011-10-11 21:11:26 +04:00
|
|
|
* particular core. This can be advantageous if you know the slab
|
2010-07-27 02:47:55 +04:00
|
|
|
* object will be short lived and primarily accessed from one core.
|
|
|
|
*
|
|
|
|
* XXX: Slab coloring may also yield performance improvements and would
|
|
|
|
* be desirable to implement.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct list_head spl_kmem_cache_list; /* List of caches */
|
|
|
|
struct rw_semaphore spl_kmem_cache_sem; /* Cache list lock */
|
2012-12-10 22:53:46 +04:00
|
|
|
taskq_t *spl_kmem_cache_taskq; /* Task queue for ageing / reclaim */
|
2010-07-27 02:47:55 +04:00
|
|
|
|
2013-01-12 02:29:32 +04:00
|
|
|
static void spl_cache_shrink(spl_kmem_cache_t *skc, void *obj);
|
2010-07-27 02:47:55 +04:00
|
|
|
|
2011-06-17 02:39:08 +04:00
|
|
|
SPL_SHRINKER_CALLBACK_FWD_DECLARE(spl_kmem_cache_generic_shrinker);
|
2011-03-24 01:45:55 +03:00
|
|
|
SPL_SHRINKER_DECLARE(spl_kmem_cache_shrinker,
|
|
|
|
spl_kmem_cache_generic_shrinker, KMC_DEFAULT_SEEKS);
|
2010-07-27 02:47:55 +04:00
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
static void *
|
|
|
|
kv_alloc(spl_kmem_cache_t *skc, int size, int flags)
|
2008-06-28 09:04:46 +04:00
|
|
|
{
|
2008-07-01 07:28:54 +04:00
|
|
|
void *ptr;
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2009-11-13 22:12:43 +03:00
|
|
|
ASSERT(ISP2(size));
|
|
|
|
|
2012-08-18 22:06:21 +04:00
|
|
|
if (skc->skc_flags & KMC_KMEM)
|
2014-04-22 12:45:36 +04:00
|
|
|
ptr = (void *)__get_free_pages(flags | __GFP_COMP,
|
|
|
|
get_order(size));
|
2012-08-18 22:06:21 +04:00
|
|
|
else
|
2012-08-18 22:05:53 +04:00
|
|
|
ptr = __vmalloc(size, flags | __GFP_HIGHMEM, PAGE_KERNEL);
|
|
|
|
|
2009-11-13 22:12:43 +03:00
|
|
|
/* Resulting allocated memory will be page aligned */
|
|
|
|
ASSERT(IS_P2ALIGNED(ptr, PAGE_SIZE));
|
2008-06-28 09:04:46 +04:00
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
return ptr;
|
|
|
|
}
|
2008-06-28 09:04:46 +04:00
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
static void
|
|
|
|
kv_free(spl_kmem_cache_t *skc, void *ptr, int size)
|
|
|
|
{
|
2009-11-13 22:12:43 +03:00
|
|
|
ASSERT(IS_P2ALIGNED(ptr, PAGE_SIZE));
|
|
|
|
ASSERT(ISP2(size));
|
|
|
|
|
2012-05-02 02:49:07 +04:00
|
|
|
/*
|
|
|
|
* The Linux direct reclaim path uses this out of band value to
|
|
|
|
* determine if forward progress is being made. Normally this is
|
|
|
|
* incremented by kmem_freepages() which is part of the various
|
|
|
|
* Linux slab implementations. However, since we are using none
|
|
|
|
* of that infrastructure we are responsible for incrementing it.
|
|
|
|
*/
|
|
|
|
if (current->reclaim_state)
|
|
|
|
current->reclaim_state->reclaimed_slab += size >> PAGE_SHIFT;
|
|
|
|
|
2009-11-13 22:12:43 +03:00
|
|
|
if (skc->skc_flags & KMC_KMEM)
|
|
|
|
free_pages((unsigned long)ptr, get_order(size));
|
|
|
|
else
|
|
|
|
vfree(ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Required space for each aligned sks.
|
|
|
|
*/
|
|
|
|
static inline uint32_t
|
|
|
|
spl_sks_size(spl_kmem_cache_t *skc)
|
|
|
|
{
|
|
|
|
return P2ROUNDUP_TYPED(sizeof(spl_kmem_slab_t),
|
|
|
|
skc->skc_obj_align, uint32_t);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Required space for each aligned object.
|
|
|
|
*/
|
|
|
|
static inline uint32_t
|
|
|
|
spl_obj_size(spl_kmem_cache_t *skc)
|
|
|
|
{
|
|
|
|
uint32_t align = skc->skc_obj_align;
|
|
|
|
|
|
|
|
return P2ROUNDUP_TYPED(skc->skc_obj_size, align, uint32_t) +
|
|
|
|
P2ROUNDUP_TYPED(sizeof(spl_kmem_obj_t), align, uint32_t);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Lookup the spl_kmem_object_t for an object given that object.
|
|
|
|
*/
|
|
|
|
static inline spl_kmem_obj_t *
|
|
|
|
spl_sko_from_obj(spl_kmem_cache_t *skc, void *obj)
|
|
|
|
{
|
|
|
|
return obj + P2ROUNDUP_TYPED(skc->skc_obj_size,
|
|
|
|
skc->skc_obj_align, uint32_t);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Required space for each offslab object taking in to account alignment
|
|
|
|
* restrictions and the power-of-two requirement of kv_alloc().
|
|
|
|
*/
|
|
|
|
static inline uint32_t
|
|
|
|
spl_offslab_size(spl_kmem_cache_t *skc)
|
|
|
|
{
|
2014-10-01 02:07:07 +04:00
|
|
|
return 1UL << (fls64(spl_obj_size(skc)) + 1);
|
2008-06-28 09:04:46 +04:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* It's important that we pack the spl_kmem_obj_t structure and the
|
2009-01-26 20:02:04 +03:00
|
|
|
* actual objects in to one large address space to minimize the number
|
|
|
|
* of calls to the allocator. It is far better to do a few large
|
|
|
|
* allocations and then subdivide it ourselves. Now which allocator
|
|
|
|
* we use requires balancing a few trade offs.
|
|
|
|
*
|
|
|
|
* For small objects we use kmem_alloc() because as long as you are
|
|
|
|
* only requesting a small number of pages (ideally just one) its cheap.
|
|
|
|
* However, when you start requesting multiple pages with kmem_alloc()
|
2011-10-11 21:11:26 +04:00
|
|
|
* it gets increasingly expensive since it requires contiguous pages.
|
2009-01-26 20:02:04 +03:00
|
|
|
* For this reason we shift to vmem_alloc() for slabs of large objects
|
2011-10-11 21:11:26 +04:00
|
|
|
* which removes the need for contiguous pages. We do not use
|
2009-01-26 20:02:04 +03:00
|
|
|
* vmem_alloc() in all cases because there is significant locking
|
|
|
|
* overhead in __get_vm_area_node(). This function takes a single
|
2011-10-11 21:11:26 +04:00
|
|
|
* global lock when acquiring an available virtual address range which
|
2009-01-26 20:02:04 +03:00
|
|
|
* serializes all vmem_alloc()'s for all slab caches. Using slightly
|
|
|
|
* different allocation functions for small and large objects should
|
|
|
|
* give us the best of both worlds.
|
|
|
|
*
|
|
|
|
* KMC_ONSLAB KMC_OFFSLAB
|
|
|
|
*
|
|
|
|
* +------------------------+ +-----------------+
|
|
|
|
* | spl_kmem_slab_t --+-+ | | spl_kmem_slab_t |---+-+
|
|
|
|
* | skc_obj_size <-+ | | +-----------------+ | |
|
|
|
|
* | spl_kmem_obj_t | | | |
|
|
|
|
* | skc_obj_size <---+ | +-----------------+ | |
|
|
|
|
* | spl_kmem_obj_t | | | skc_obj_size | <-+ |
|
|
|
|
* | ... v | | spl_kmem_obj_t | |
|
|
|
|
* +------------------------+ +-----------------+ v
|
|
|
|
*/
|
2008-06-28 09:04:46 +04:00
|
|
|
static spl_kmem_slab_t *
|
2008-07-01 07:28:54 +04:00
|
|
|
spl_slab_alloc(spl_kmem_cache_t *skc, int flags)
|
2008-06-28 09:04:46 +04:00
|
|
|
{
|
|
|
|
spl_kmem_slab_t *sks;
|
2008-07-01 07:28:54 +04:00
|
|
|
spl_kmem_obj_t *sko, *n;
|
|
|
|
void *base, *obj;
|
2009-11-13 22:12:43 +03:00
|
|
|
uint32_t obj_size, offslab_size = 0;
|
|
|
|
int i, rc = 0;
|
2009-01-26 20:02:04 +03:00
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
base = kv_alloc(skc, skc->skc_slab_size, flags);
|
|
|
|
if (base == NULL)
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(NULL);
|
2008-06-28 09:04:46 +04:00
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
sks = (spl_kmem_slab_t *)base;
|
|
|
|
sks->sks_magic = SKS_MAGIC;
|
|
|
|
sks->sks_objs = skc->skc_slab_objs;
|
|
|
|
sks->sks_age = jiffies;
|
|
|
|
sks->sks_cache = skc;
|
|
|
|
INIT_LIST_HEAD(&sks->sks_list);
|
|
|
|
INIT_LIST_HEAD(&sks->sks_free_list);
|
|
|
|
sks->sks_ref = 0;
|
2009-11-13 22:12:43 +03:00
|
|
|
obj_size = spl_obj_size(skc);
|
2009-01-26 20:02:04 +03:00
|
|
|
|
2011-10-11 21:03:29 +04:00
|
|
|
if (skc->skc_flags & KMC_OFFSLAB)
|
2009-11-13 22:12:43 +03:00
|
|
|
offslab_size = spl_offslab_size(skc);
|
2008-06-28 09:04:46 +04:00
|
|
|
|
|
|
|
for (i = 0; i < sks->sks_objs; i++) {
|
2008-07-01 07:28:54 +04:00
|
|
|
if (skc->skc_flags & KMC_OFFSLAB) {
|
2009-11-13 22:12:43 +03:00
|
|
|
obj = kv_alloc(skc, offslab_size, flags);
|
2008-07-01 07:28:54 +04:00
|
|
|
if (!obj)
|
2010-07-20 22:55:37 +04:00
|
|
|
SGOTO(out, rc = -ENOMEM);
|
2008-07-01 07:28:54 +04:00
|
|
|
} else {
|
2009-11-13 22:12:43 +03:00
|
|
|
obj = base + spl_sks_size(skc) + (i * obj_size);
|
2008-07-01 07:28:54 +04:00
|
|
|
}
|
|
|
|
|
2009-11-13 22:12:43 +03:00
|
|
|
ASSERT(IS_P2ALIGNED(obj, skc->skc_obj_align));
|
|
|
|
sko = spl_sko_from_obj(skc, obj);
|
2008-06-28 09:04:46 +04:00
|
|
|
sko->sko_addr = obj;
|
|
|
|
sko->sko_magic = SKO_MAGIC;
|
|
|
|
sko->sko_slab = sks;
|
|
|
|
INIT_LIST_HEAD(&sko->sko_list);
|
|
|
|
list_add_tail(&sko->sko_list, &sks->sks_free_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
list_for_each_entry(sko, &sks->sks_free_list, sko_list)
|
|
|
|
if (skc->skc_ctor)
|
|
|
|
skc->skc_ctor(sko->sko_addr, skc->skc_private, flags);
|
2008-06-14 03:41:06 +04:00
|
|
|
out:
|
2008-07-01 07:28:54 +04:00
|
|
|
if (rc) {
|
|
|
|
if (skc->skc_flags & KMC_OFFSLAB)
|
2009-01-26 20:02:04 +03:00
|
|
|
list_for_each_entry_safe(sko, n, &sks->sks_free_list,
|
|
|
|
sko_list)
|
2009-11-13 22:12:43 +03:00
|
|
|
kv_free(skc, sko->sko_addr, offslab_size);
|
2008-06-28 09:04:46 +04:00
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
kv_free(skc, base, skc->skc_slab_size);
|
|
|
|
sks = NULL;
|
2008-06-28 09:04:46 +04:00
|
|
|
}
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(sks);
|
2008-06-28 09:04:46 +04:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Remove a slab from complete or partial list, it must be called with
|
|
|
|
* the 'skc->skc_lock' held but the actual free must be performed
|
|
|
|
* outside the lock to prevent deadlocking on vmem addresses.
|
2008-06-28 09:04:46 +04:00
|
|
|
*/
|
2008-02-26 23:36:04 +03:00
|
|
|
static void
|
2009-01-31 07:54:49 +03:00
|
|
|
spl_slab_free(spl_kmem_slab_t *sks,
|
|
|
|
struct list_head *sks_list, struct list_head *sko_list)
|
|
|
|
{
|
2008-06-14 03:41:06 +04:00
|
|
|
spl_kmem_cache_t *skc;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-02 21:28:49 +04:00
|
|
|
|
2008-06-14 03:41:06 +04:00
|
|
|
ASSERT(sks->sks_magic == SKS_MAGIC);
|
2008-06-26 00:57:45 +04:00
|
|
|
ASSERT(sks->sks_ref == 0);
|
2008-05-07 00:38:28 +04:00
|
|
|
|
2008-06-28 09:04:46 +04:00
|
|
|
skc = sks->sks_cache;
|
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2008-06-24 21:18:15 +04:00
|
|
|
ASSERT(spin_is_locked(&skc->skc_lock));
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2009-02-13 21:28:55 +03:00
|
|
|
/*
|
|
|
|
* Update slab/objects counters in the cache, then remove the
|
|
|
|
* slab from the skc->skc_partial_list. Finally add the slab
|
|
|
|
* and all its objects in to the private work lists where the
|
|
|
|
* destructors will be called and the memory freed to the system.
|
|
|
|
*/
|
2008-06-28 09:04:46 +04:00
|
|
|
skc->skc_obj_total -= sks->sks_objs;
|
|
|
|
skc->skc_slab_total--;
|
|
|
|
list_del(&sks->sks_list);
|
2009-01-31 07:54:49 +03:00
|
|
|
list_add(&sks->sks_list, sks_list);
|
2009-02-13 21:28:55 +03:00
|
|
|
list_splice_init(&sks->sks_free_list, sko_list);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-06-14 03:41:06 +04:00
|
|
|
}
|
2008-05-07 00:38:28 +04:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Traverses all the partial slabs attached to a cache and free those
|
|
|
|
* which which are currently empty, and have not been touched for
|
2009-02-13 00:32:10 +03:00
|
|
|
* skc_delay seconds to avoid thrashing. The count argument is
|
|
|
|
* passed to optionally cap the number of slabs reclaimed, a count
|
|
|
|
* of zero means try and reclaim everything. When flag is set we
|
|
|
|
* always free an available slab regardless of age.
|
2009-01-31 07:54:49 +03:00
|
|
|
*/
|
|
|
|
static void
|
2009-02-13 00:32:10 +03:00
|
|
|
spl_slab_reclaim(spl_kmem_cache_t *skc, int count, int flag)
|
2008-06-14 03:41:06 +04:00
|
|
|
{
|
|
|
|
spl_kmem_slab_t *sks, *m;
|
2009-01-31 07:54:49 +03:00
|
|
|
spl_kmem_obj_t *sko, *n;
|
|
|
|
LIST_HEAD(sks_list);
|
|
|
|
LIST_HEAD(sko_list);
|
2009-11-13 22:12:43 +03:00
|
|
|
uint32_t size = 0;
|
|
|
|
int i = 0;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-14 03:41:06 +04:00
|
|
|
|
|
|
|
/*
|
2009-01-31 07:54:49 +03:00
|
|
|
* Move empty slabs and objects which have not been touched in
|
|
|
|
* skc_delay seconds on to private lists to be freed outside
|
2009-02-13 21:28:55 +03:00
|
|
|
* the spin lock. This delay time is important to avoid thrashing
|
|
|
|
* however when flag is set the delay will not be used.
|
2008-06-14 03:41:06 +04:00
|
|
|
*/
|
2009-01-31 07:54:49 +03:00
|
|
|
spin_lock(&skc->skc_lock);
|
2009-02-13 21:28:55 +03:00
|
|
|
list_for_each_entry_safe_reverse(sks,m,&skc->skc_partial_list,sks_list){
|
|
|
|
/*
|
|
|
|
* All empty slabs are at the end of skc->skc_partial_list,
|
|
|
|
* therefore once a non-empty slab is found we can stop
|
|
|
|
* scanning. Additionally, stop when reaching the target
|
2011-10-11 21:11:26 +04:00
|
|
|
* reclaim 'count' if a non-zero threshold is given.
|
2009-02-13 21:28:55 +03:00
|
|
|
*/
|
2012-04-28 02:10:02 +04:00
|
|
|
if ((sks->sks_ref > 0) || (count && i >= count))
|
2009-02-13 00:32:10 +03:00
|
|
|
break;
|
|
|
|
|
|
|
|
if (time_after(jiffies,sks->sks_age+skc->skc_delay*HZ)||flag) {
|
2009-01-31 07:54:49 +03:00
|
|
|
spl_slab_free(sks, &sks_list, &sko_list);
|
2009-02-13 00:32:10 +03:00
|
|
|
i++;
|
|
|
|
}
|
2009-01-31 07:54:49 +03:00
|
|
|
}
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
|
|
|
/*
|
2009-02-13 21:28:55 +03:00
|
|
|
* The following two loops ensure all the object destructors are
|
|
|
|
* run, any offslab objects are freed, and the slabs themselves
|
|
|
|
* are freed. This is all done outside the skc->skc_lock since
|
|
|
|
* this allows the destructor to sleep, and allows us to perform
|
|
|
|
* a conditional reschedule when a freeing a large number of
|
|
|
|
* objects and slabs back to the system.
|
2009-01-31 07:54:49 +03:00
|
|
|
*/
|
2009-02-13 21:28:55 +03:00
|
|
|
if (skc->skc_flags & KMC_OFFSLAB)
|
2009-11-13 22:12:43 +03:00
|
|
|
size = spl_offslab_size(skc);
|
2009-01-31 07:54:49 +03:00
|
|
|
|
2009-02-13 21:28:55 +03:00
|
|
|
list_for_each_entry_safe(sko, n, &sko_list, sko_list) {
|
|
|
|
ASSERT(sko->sko_magic == SKO_MAGIC);
|
|
|
|
|
|
|
|
if (skc->skc_dtor)
|
|
|
|
skc->skc_dtor(sko->sko_addr, skc->skc_private);
|
|
|
|
|
|
|
|
if (skc->skc_flags & KMC_OFFSLAB)
|
2009-01-31 07:54:49 +03:00
|
|
|
kv_free(skc, sko->sko_addr, size);
|
2008-06-14 03:41:06 +04:00
|
|
|
}
|
|
|
|
|
2009-02-13 00:32:10 +03:00
|
|
|
list_for_each_entry_safe(sks, m, &sks_list, sks_list) {
|
2009-02-13 21:28:55 +03:00
|
|
|
ASSERT(sks->sks_magic == SKS_MAGIC);
|
2009-01-31 07:54:49 +03:00
|
|
|
kv_free(skc, sks, skc->skc_slab_size);
|
2009-02-13 00:32:10 +03:00
|
|
|
}
|
2009-01-31 07:54:49 +03:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-02-26 23:36:04 +03:00
|
|
|
}
|
|
|
|
|
2012-10-30 21:45:50 +04:00
|
|
|
static spl_kmem_emergency_t *
|
|
|
|
spl_emergency_search(struct rb_root *root, void *obj)
|
|
|
|
{
|
|
|
|
struct rb_node *node = root->rb_node;
|
|
|
|
spl_kmem_emergency_t *ske;
|
|
|
|
unsigned long address = (unsigned long)obj;
|
|
|
|
|
|
|
|
while (node) {
|
|
|
|
ske = container_of(node, spl_kmem_emergency_t, ske_node);
|
|
|
|
|
|
|
|
if (address < (unsigned long)ske->ske_obj)
|
|
|
|
node = node->rb_left;
|
|
|
|
else if (address > (unsigned long)ske->ske_obj)
|
|
|
|
node = node->rb_right;
|
|
|
|
else
|
|
|
|
return ske;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
spl_emergency_insert(struct rb_root *root, spl_kmem_emergency_t *ske)
|
|
|
|
{
|
|
|
|
struct rb_node **new = &(root->rb_node), *parent = NULL;
|
|
|
|
spl_kmem_emergency_t *ske_tmp;
|
|
|
|
unsigned long address = (unsigned long)ske->ske_obj;
|
|
|
|
|
|
|
|
while (*new) {
|
|
|
|
ske_tmp = container_of(*new, spl_kmem_emergency_t, ske_node);
|
|
|
|
|
|
|
|
parent = *new;
|
|
|
|
if (address < (unsigned long)ske_tmp->ske_obj)
|
|
|
|
new = &((*new)->rb_left);
|
|
|
|
else if (address > (unsigned long)ske_tmp->ske_obj)
|
|
|
|
new = &((*new)->rb_right);
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
rb_link_node(&ske->ske_node, parent, new);
|
|
|
|
rb_insert_color(&ske->ske_node, root);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
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-08 03:59:50 +04:00
|
|
|
/*
|
2012-10-30 21:45:50 +04:00
|
|
|
* Allocate a single emergency object and track it in a red black tree.
|
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-08 03:59:50 +04:00
|
|
|
*/
|
|
|
|
static int
|
|
|
|
spl_emergency_alloc(spl_kmem_cache_t *skc, int flags, void **obj)
|
|
|
|
{
|
|
|
|
spl_kmem_emergency_t *ske;
|
|
|
|
int empty;
|
|
|
|
SENTRY;
|
|
|
|
|
|
|
|
/* Last chance use a partial slab if one now exists */
|
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
empty = list_empty(&skc->skc_partial_list);
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
if (!empty)
|
|
|
|
SRETURN(-EEXIST);
|
|
|
|
|
|
|
|
ske = kmalloc(sizeof(*ske), flags);
|
|
|
|
if (ske == NULL)
|
|
|
|
SRETURN(-ENOMEM);
|
|
|
|
|
|
|
|
ske->ske_obj = kmalloc(skc->skc_obj_size, flags);
|
|
|
|
if (ske->ske_obj == NULL) {
|
|
|
|
kfree(ske);
|
|
|
|
SRETURN(-ENOMEM);
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_lock(&skc->skc_lock);
|
2012-10-30 21:45:50 +04:00
|
|
|
empty = spl_emergency_insert(&skc->skc_emergency_tree, ske);
|
|
|
|
if (likely(empty)) {
|
|
|
|
skc->skc_obj_total++;
|
|
|
|
skc->skc_obj_emergency++;
|
|
|
|
if (skc->skc_obj_emergency > skc->skc_obj_emergency_max)
|
|
|
|
skc->skc_obj_emergency_max = skc->skc_obj_emergency;
|
|
|
|
}
|
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-08 03:59:50 +04:00
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
2012-10-30 21:45:50 +04:00
|
|
|
if (unlikely(!empty)) {
|
|
|
|
kfree(ske->ske_obj);
|
|
|
|
kfree(ske);
|
|
|
|
SRETURN(-EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (skc->skc_ctor)
|
|
|
|
skc->skc_ctor(ske->ske_obj, skc->skc_private, flags);
|
|
|
|
|
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-08 03:59:50 +04:00
|
|
|
*obj = ske->ske_obj;
|
|
|
|
|
|
|
|
SRETURN(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2012-10-30 21:45:50 +04:00
|
|
|
* Locate the passed object in the red black tree and free it.
|
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-08 03:59:50 +04:00
|
|
|
*/
|
|
|
|
static int
|
|
|
|
spl_emergency_free(spl_kmem_cache_t *skc, void *obj)
|
|
|
|
{
|
2012-10-30 21:45:50 +04:00
|
|
|
spl_kmem_emergency_t *ske;
|
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-08 03:59:50 +04:00
|
|
|
SENTRY;
|
|
|
|
|
|
|
|
spin_lock(&skc->skc_lock);
|
2012-10-30 21:45:50 +04:00
|
|
|
ske = spl_emergency_search(&skc->skc_emergency_tree, obj);
|
|
|
|
if (likely(ske)) {
|
|
|
|
rb_erase(&ske->ske_node, &skc->skc_emergency_tree);
|
|
|
|
skc->skc_obj_emergency--;
|
|
|
|
skc->skc_obj_total--;
|
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-08 03:59:50 +04:00
|
|
|
}
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
2012-10-30 21:45:50 +04:00
|
|
|
if (unlikely(ske == NULL))
|
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-08 03:59:50 +04:00
|
|
|
SRETURN(-ENOENT);
|
|
|
|
|
|
|
|
if (skc->skc_dtor)
|
|
|
|
skc->skc_dtor(ske->ske_obj, skc->skc_private);
|
|
|
|
|
|
|
|
kfree(ske->ske_obj);
|
|
|
|
kfree(ske);
|
|
|
|
|
|
|
|
SRETURN(0);
|
|
|
|
}
|
|
|
|
|
2013-01-12 02:29:32 +04:00
|
|
|
/*
|
|
|
|
* Release objects from the per-cpu magazine back to their slab. The flush
|
|
|
|
* argument contains the max number of entries to remove from the magazine.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
__spl_cache_flush(spl_kmem_cache_t *skc, spl_kmem_magazine_t *skm, int flush)
|
|
|
|
{
|
|
|
|
int i, count = MIN(flush, skm->skm_avail);
|
|
|
|
SENTRY;
|
|
|
|
|
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
|
|
|
ASSERT(skm->skm_magic == SKM_MAGIC);
|
|
|
|
ASSERT(spin_is_locked(&skc->skc_lock));
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
spl_cache_shrink(skc, skm->skm_objs[i]);
|
|
|
|
|
|
|
|
skm->skm_avail -= count;
|
|
|
|
memmove(skm->skm_objs, &(skm->skm_objs[count]),
|
|
|
|
sizeof(void *) * skm->skm_avail);
|
|
|
|
|
|
|
|
SEXIT;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
spl_cache_flush(spl_kmem_cache_t *skc, spl_kmem_magazine_t *skm, int flush)
|
|
|
|
{
|
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
__spl_cache_flush(skc, skm, flush);
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
static void
|
|
|
|
spl_magazine_age(void *data)
|
2008-02-26 23:36:04 +03:00
|
|
|
{
|
2012-12-10 22:53:46 +04:00
|
|
|
spl_kmem_cache_t *skc = (spl_kmem_cache_t *)data;
|
|
|
|
spl_kmem_magazine_t *skm = skc->skc_mag[smp_processor_id()];
|
2009-02-18 02:52:18 +03:00
|
|
|
|
|
|
|
ASSERT(skm->skm_magic == SKM_MAGIC);
|
2012-12-10 22:53:46 +04:00
|
|
|
ASSERT(skm->skm_cpu == smp_processor_id());
|
2013-01-12 02:29:32 +04:00
|
|
|
ASSERT(irqs_disabled());
|
|
|
|
|
|
|
|
/* There are no available objects or they are too young to age out */
|
|
|
|
if ((skm->skm_avail == 0) ||
|
|
|
|
time_before(jiffies, skm->skm_age + skc->skc_delay * HZ))
|
|
|
|
return;
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2013-01-12 02:29:32 +04:00
|
|
|
/*
|
|
|
|
* Because we're executing in interrupt context we may have
|
|
|
|
* interrupted the holder of this lock. To avoid a potential
|
|
|
|
* deadlock return if the lock is contended.
|
|
|
|
*/
|
|
|
|
if (!spin_trylock(&skc->skc_lock))
|
|
|
|
return;
|
|
|
|
|
|
|
|
__spl_cache_flush(skc, skm, skm->skm_refill);
|
|
|
|
spin_unlock(&skc->skc_lock);
|
2009-01-31 07:54:49 +03:00
|
|
|
}
|
2008-05-15 21:10:30 +04:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
2012-12-10 22:53:46 +04:00
|
|
|
* Called regularly to keep a downward pressure on the cache.
|
|
|
|
*
|
|
|
|
* Objects older than skc->skc_delay seconds in the per-cpu magazines will
|
|
|
|
* be returned to the caches. This is done to prevent idle magazines from
|
|
|
|
* holding memory which could be better used elsewhere. The delay is
|
|
|
|
* present to prevent thrashing the magazine.
|
|
|
|
*
|
|
|
|
* The newly released objects may result in empty partial slabs. Those
|
|
|
|
* slabs should be released to the system. Otherwise moving the objects
|
|
|
|
* out of the magazines is just wasted work.
|
2009-01-31 07:54:49 +03:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
spl_cache_age(void *data)
|
|
|
|
{
|
2012-12-10 22:53:46 +04:00
|
|
|
spl_kmem_cache_t *skc = (spl_kmem_cache_t *)data;
|
|
|
|
taskqid_t id = 0;
|
2009-01-31 07:54:49 +03:00
|
|
|
|
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2012-12-10 22:53:46 +04:00
|
|
|
|
2013-01-19 03:44:27 +04:00
|
|
|
/* Dynamically disabled at run time */
|
|
|
|
if (!(spl_kmem_cache_expire & KMC_EXPIRE_AGE))
|
|
|
|
return;
|
|
|
|
|
2012-12-10 22:53:46 +04:00
|
|
|
atomic_inc(&skc->skc_ref);
|
2013-12-09 02:01:45 +04:00
|
|
|
|
|
|
|
if (!(skc->skc_flags & KMC_NOMAGAZINE))
|
2014-10-02 01:35:41 +04:00
|
|
|
on_each_cpu(spl_magazine_age, skc, 1);
|
2013-12-09 02:01:45 +04:00
|
|
|
|
2009-02-13 00:32:10 +03:00
|
|
|
spl_slab_reclaim(skc, skc->skc_reap, 0);
|
2009-01-31 07:54:49 +03:00
|
|
|
|
2012-12-10 22:53:46 +04:00
|
|
|
while (!test_bit(KMC_BIT_DESTROY, &skc->skc_flags) && !id) {
|
|
|
|
id = taskq_dispatch_delay(
|
|
|
|
spl_kmem_cache_taskq, spl_cache_age, skc, TQ_SLEEP,
|
|
|
|
ddi_get_lbolt() + skc->skc_delay / 3 * HZ);
|
|
|
|
|
|
|
|
/* Destroy issued after dispatch immediately cancel it */
|
|
|
|
if (test_bit(KMC_BIT_DESTROY, &skc->skc_flags) && id)
|
|
|
|
taskq_cancel_id(spl_kmem_cache_taskq, id);
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
skc->skc_taskqid = id;
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
|
|
|
atomic_dec(&skc->skc_ref);
|
2008-06-14 03:41:06 +04:00
|
|
|
}
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
2009-11-13 22:12:43 +03:00
|
|
|
* Size a slab based on the size of each aligned object plus spl_kmem_obj_t.
|
2014-02-06 14:08:46 +04:00
|
|
|
* When on-slab we want to target spl_kmem_cache_obj_per_slab. However,
|
2009-01-31 07:54:49 +03:00
|
|
|
* for very small objects we may end up with more than this so as not
|
|
|
|
* to waste space in the minimal allocation of a single page. Also for
|
2014-02-06 14:08:46 +04:00
|
|
|
* very large objects we may use as few as spl_kmem_cache_obj_per_slab_min,
|
2009-01-31 07:54:49 +03:00
|
|
|
* lower than this and we will fail.
|
|
|
|
*/
|
2009-01-26 20:02:04 +03:00
|
|
|
static int
|
|
|
|
spl_slab_size(spl_kmem_cache_t *skc, uint32_t *objs, uint32_t *size)
|
|
|
|
{
|
2009-11-13 22:12:43 +03:00
|
|
|
uint32_t sks_size, obj_size, max_size;
|
2009-01-26 20:02:04 +03:00
|
|
|
|
|
|
|
if (skc->skc_flags & KMC_OFFSLAB) {
|
2014-02-06 14:08:46 +04:00
|
|
|
*objs = spl_kmem_cache_obj_per_slab;
|
2013-07-20 01:39:35 +04:00
|
|
|
*size = P2ROUNDUP(sizeof(spl_kmem_slab_t), PAGE_SIZE);
|
|
|
|
SRETURN(0);
|
2009-01-26 20:02:04 +03:00
|
|
|
} else {
|
2009-11-13 22:12:43 +03:00
|
|
|
sks_size = spl_sks_size(skc);
|
|
|
|
obj_size = spl_obj_size(skc);
|
2009-01-31 07:54:49 +03:00
|
|
|
|
|
|
|
if (skc->skc_flags & KMC_KMEM)
|
2010-03-18 23:39:51 +03:00
|
|
|
max_size = ((uint32_t)1 << (MAX_ORDER-3)) * PAGE_SIZE;
|
2009-01-31 07:54:49 +03:00
|
|
|
else
|
2014-02-06 14:08:46 +04:00
|
|
|
max_size = (spl_kmem_cache_max_size * 1024 * 1024);
|
2009-01-26 20:02:04 +03:00
|
|
|
|
2009-11-13 22:12:43 +03:00
|
|
|
/* Power of two sized slab */
|
|
|
|
for (*size = PAGE_SIZE; *size <= max_size; *size *= 2) {
|
2009-01-31 07:54:49 +03:00
|
|
|
*objs = (*size - sks_size) / obj_size;
|
2014-02-06 14:08:46 +04:00
|
|
|
if (*objs >= spl_kmem_cache_obj_per_slab)
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(0);
|
2009-01-31 07:54:49 +03:00
|
|
|
}
|
2009-01-26 20:02:04 +03:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
2009-11-13 22:12:43 +03:00
|
|
|
* Unable to satisfy target objects per slab, fall back to
|
2009-01-31 07:54:49 +03:00
|
|
|
* allocating a maximally sized slab and assuming it can
|
|
|
|
* contain the minimum objects count use it. If not fail.
|
|
|
|
*/
|
|
|
|
*size = max_size;
|
|
|
|
*objs = (*size - sks_size) / obj_size;
|
2014-02-06 14:08:46 +04:00
|
|
|
if (*objs >= (spl_kmem_cache_obj_per_slab_min))
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(0);
|
2009-01-26 20:02:04 +03:00
|
|
|
}
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(-ENOSPC);
|
2009-01-26 20:02:04 +03:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Make a guess at reasonable per-cpu magazine size based on the size of
|
|
|
|
* each object and the cost of caching N of them in each magazine. Long
|
|
|
|
* term this should really adapt based on an observed usage heuristic.
|
|
|
|
*/
|
2008-06-26 00:57:45 +04:00
|
|
|
static int
|
|
|
|
spl_magazine_size(spl_kmem_cache_t *skc)
|
|
|
|
{
|
2009-11-13 22:12:43 +03:00
|
|
|
uint32_t obj_size = spl_obj_size(skc);
|
|
|
|
int size;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/* Per-magazine sizes below assume a 4Kib page size */
|
2009-11-13 22:12:43 +03:00
|
|
|
if (obj_size > (PAGE_SIZE * 256))
|
2009-01-31 07:54:49 +03:00
|
|
|
size = 4; /* Minimum 4Mib per-magazine */
|
2009-11-13 22:12:43 +03:00
|
|
|
else if (obj_size > (PAGE_SIZE * 32))
|
2009-01-31 07:54:49 +03:00
|
|
|
size = 16; /* Minimum 2Mib per-magazine */
|
2009-11-13 22:12:43 +03:00
|
|
|
else if (obj_size > (PAGE_SIZE))
|
2009-01-31 07:54:49 +03:00
|
|
|
size = 64; /* Minimum 256Kib per-magazine */
|
2009-11-13 22:12:43 +03:00
|
|
|
else if (obj_size > (PAGE_SIZE / 4))
|
2009-01-31 07:54:49 +03:00
|
|
|
size = 128; /* Minimum 128Kib per-magazine */
|
2008-06-26 00:57:45 +04:00
|
|
|
else
|
2009-01-31 07:54:49 +03:00
|
|
|
size = 256;
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(size);
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
2011-10-11 21:11:26 +04:00
|
|
|
* Allocate a per-cpu magazine to associate with a specific core.
|
2009-01-31 07:54:49 +03:00
|
|
|
*/
|
2008-06-26 00:57:45 +04:00
|
|
|
static spl_kmem_magazine_t *
|
2012-08-24 01:00:58 +04:00
|
|
|
spl_magazine_alloc(spl_kmem_cache_t *skc, int cpu)
|
2008-06-26 00:57:45 +04:00
|
|
|
{
|
|
|
|
spl_kmem_magazine_t *skm;
|
|
|
|
int size = sizeof(spl_kmem_magazine_t) +
|
|
|
|
sizeof(void *) * skc->skc_mag_size;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2012-08-24 01:00:58 +04:00
|
|
|
skm = kmem_alloc_node(size, KM_SLEEP, cpu_to_node(cpu));
|
2008-06-26 00:57:45 +04:00
|
|
|
if (skm) {
|
|
|
|
skm->skm_magic = SKM_MAGIC;
|
|
|
|
skm->skm_avail = 0;
|
|
|
|
skm->skm_size = skc->skc_mag_size;
|
|
|
|
skm->skm_refill = skc->skc_mag_refill;
|
2009-02-18 02:52:18 +03:00
|
|
|
skm->skm_cache = skc;
|
2009-01-31 07:54:49 +03:00
|
|
|
skm->skm_age = jiffies;
|
2012-08-24 01:00:58 +04:00
|
|
|
skm->skm_cpu = cpu;
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(skm);
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
2011-10-11 21:11:26 +04:00
|
|
|
* Free a per-cpu magazine associated with a specific core.
|
2009-01-31 07:54:49 +03:00
|
|
|
*/
|
2008-06-26 00:57:45 +04:00
|
|
|
static void
|
|
|
|
spl_magazine_free(spl_kmem_magazine_t *skm)
|
|
|
|
{
|
2008-11-04 00:06:04 +03:00
|
|
|
int size = sizeof(spl_kmem_magazine_t) +
|
|
|
|
sizeof(void *) * skm->skm_size;
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-26 00:57:45 +04:00
|
|
|
ASSERT(skm->skm_magic == SKM_MAGIC);
|
|
|
|
ASSERT(skm->skm_avail == 0);
|
2008-11-04 00:06:04 +03:00
|
|
|
|
|
|
|
kmem_free(skm, size);
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Create all pre-cpu magazines of reasonable sizes.
|
|
|
|
*/
|
2008-06-26 00:57:45 +04:00
|
|
|
static int
|
|
|
|
spl_magazine_create(spl_kmem_cache_t *skc)
|
|
|
|
{
|
2009-02-13 00:32:10 +03:00
|
|
|
int i;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
if (skc->skc_flags & KMC_NOMAGAZINE)
|
|
|
|
SRETURN(0);
|
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
skc->skc_mag_size = spl_magazine_size(skc);
|
2009-01-31 07:54:49 +03:00
|
|
|
skc->skc_mag_refill = (skc->skc_mag_size + 1) / 2;
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2009-02-13 00:32:10 +03:00
|
|
|
for_each_online_cpu(i) {
|
2012-08-24 01:00:58 +04:00
|
|
|
skc->skc_mag[i] = spl_magazine_alloc(skc, i);
|
2009-02-13 00:32:10 +03:00
|
|
|
if (!skc->skc_mag[i]) {
|
|
|
|
for (i--; i >= 0; i--)
|
|
|
|
spl_magazine_free(skc->skc_mag[i]);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(-ENOMEM);
|
2009-02-13 00:32:10 +03:00
|
|
|
}
|
|
|
|
}
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(0);
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Destroy all pre-cpu magazines.
|
|
|
|
*/
|
2008-06-26 00:57:45 +04:00
|
|
|
static void
|
|
|
|
spl_magazine_destroy(spl_kmem_cache_t *skc)
|
|
|
|
{
|
2009-02-13 00:32:10 +03:00
|
|
|
spl_kmem_magazine_t *skm;
|
|
|
|
int i;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2009-02-13 00:32:10 +03:00
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
if (skc->skc_flags & KMC_NOMAGAZINE) {
|
|
|
|
SEXIT;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-02-13 00:32:10 +03:00
|
|
|
for_each_online_cpu(i) {
|
|
|
|
skm = skc->skc_mag[i];
|
2013-01-12 02:29:32 +04:00
|
|
|
spl_cache_flush(skc, skm, skm->skm_avail);
|
2009-02-13 00:32:10 +03:00
|
|
|
spl_magazine_free(skm);
|
|
|
|
}
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Create a object cache based on the following arguments:
|
|
|
|
* name cache name
|
|
|
|
* size cache object size
|
|
|
|
* align cache object alignment
|
|
|
|
* ctor cache object constructor
|
|
|
|
* dtor cache object destructor
|
|
|
|
* reclaim cache object reclaim
|
|
|
|
* priv cache private data for ctor/dtor/reclaim
|
|
|
|
* vmp unused must be NULL
|
|
|
|
* flags
|
|
|
|
* KMC_NOTOUCH Disable cache object aging (unsupported)
|
|
|
|
* KMC_NODEBUG Disable debugging (unsupported)
|
|
|
|
* KMC_NOHASH Disable hashing (unsupported)
|
|
|
|
* KMC_QCACHE Disable qcache (unsupported)
|
2013-12-09 02:01:45 +04:00
|
|
|
* KMC_NOMAGAZINE Enabled for kmem/vmem, Disabled for Linux slab
|
2009-01-31 07:54:49 +03:00
|
|
|
* KMC_KMEM Force kmem backed cache
|
|
|
|
* KMC_VMEM Force vmem backed cache
|
2013-12-09 02:01:45 +04:00
|
|
|
* KMC_SLAB Force Linux slab backed cache
|
2009-01-31 07:54:49 +03:00
|
|
|
* KMC_OFFSLAB Locate objects off the slab
|
|
|
|
*/
|
2008-06-14 03:41:06 +04:00
|
|
|
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)
|
|
|
|
{
|
|
|
|
spl_kmem_cache_t *skc;
|
2012-12-10 23:01:08 +04:00
|
|
|
int rc;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-04-21 21:29:47 +04:00
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
ASSERTF(!(flags & KMC_NOMAGAZINE), "Bad KMC_NOMAGAZINE (%x)\n", flags);
|
|
|
|
ASSERTF(!(flags & KMC_NOHASH), "Bad KMC_NOHASH (%x)\n", flags);
|
|
|
|
ASSERTF(!(flags & KMC_QCACHE), "Bad KMC_QCACHE (%x)\n", flags);
|
2009-01-26 20:02:04 +03:00
|
|
|
ASSERT(vmp == NULL);
|
2008-07-01 07:28:54 +04:00
|
|
|
|
2012-12-10 23:01:08 +04:00
|
|
|
might_sleep();
|
2008-04-03 20:33:31 +04:00
|
|
|
|
2012-12-10 23:01:08 +04:00
|
|
|
/*
|
|
|
|
* Allocate memory for a new cache an initialize it. Unfortunately,
|
2010-05-20 03:53:13 +04:00
|
|
|
* this usually ends up being a large allocation of ~32k because
|
|
|
|
* we need to allocate enough memory for the worst case number of
|
|
|
|
* cpus in the magazine, skc_mag[NR_CPUS]. Because of this we
|
2012-12-10 23:01:08 +04:00
|
|
|
* explicitly pass KM_NODEBUG to suppress the kmem warning
|
|
|
|
*/
|
|
|
|
skc = kmem_zalloc(sizeof(*skc), KM_SLEEP| KM_NODEBUG);
|
2008-06-26 23:49:42 +04:00
|
|
|
if (skc == NULL)
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(NULL);
|
2008-04-16 00:53:36 +04:00
|
|
|
|
2008-06-14 03:41:06 +04:00
|
|
|
skc->skc_magic = SKC_MAGIC;
|
|
|
|
skc->skc_name_size = strlen(name) + 1;
|
2012-12-10 23:01:08 +04:00
|
|
|
skc->skc_name = (char *)kmem_alloc(skc->skc_name_size, KM_SLEEP);
|
2008-06-14 03:41:06 +04:00
|
|
|
if (skc->skc_name == NULL) {
|
|
|
|
kmem_free(skc, sizeof(*skc));
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(NULL);
|
2008-06-14 03:41:06 +04:00
|
|
|
}
|
|
|
|
strncpy(skc->skc_name, name, skc->skc_name_size);
|
|
|
|
|
2008-06-26 23:49:42 +04:00
|
|
|
skc->skc_ctor = ctor;
|
|
|
|
skc->skc_dtor = dtor;
|
|
|
|
skc->skc_reclaim = reclaim;
|
2008-06-14 03:41:06 +04:00
|
|
|
skc->skc_private = priv;
|
|
|
|
skc->skc_vmp = vmp;
|
2013-12-09 02:01:45 +04:00
|
|
|
skc->skc_linux_cache = NULL;
|
2008-06-14 03:41:06 +04:00
|
|
|
skc->skc_flags = flags;
|
|
|
|
skc->skc_obj_size = size;
|
2009-01-26 20:02:04 +03:00
|
|
|
skc->skc_obj_align = SPL_KMEM_CACHE_ALIGN;
|
2008-06-14 03:41:06 +04:00
|
|
|
skc->skc_delay = SPL_KMEM_CACHE_DELAY;
|
2009-02-13 00:32:10 +03:00
|
|
|
skc->skc_reap = SPL_KMEM_CACHE_REAP;
|
2009-01-31 07:54:49 +03:00
|
|
|
atomic_set(&skc->skc_ref, 0);
|
2008-06-14 03:41:06 +04:00
|
|
|
|
|
|
|
INIT_LIST_HEAD(&skc->skc_list);
|
|
|
|
INIT_LIST_HEAD(&skc->skc_complete_list);
|
|
|
|
INIT_LIST_HEAD(&skc->skc_partial_list);
|
2012-10-30 21:45:50 +04:00
|
|
|
skc->skc_emergency_tree = RB_ROOT;
|
2008-06-24 21:18:15 +04:00
|
|
|
spin_lock_init(&skc->skc_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-08 03:59:50 +04:00
|
|
|
init_waitqueue_head(&skc->skc_waitq);
|
2008-06-26 23:49:42 +04:00
|
|
|
skc->skc_slab_fail = 0;
|
|
|
|
skc->skc_slab_create = 0;
|
|
|
|
skc->skc_slab_destroy = 0;
|
2008-06-14 03:41:06 +04:00
|
|
|
skc->skc_slab_total = 0;
|
|
|
|
skc->skc_slab_alloc = 0;
|
|
|
|
skc->skc_slab_max = 0;
|
|
|
|
skc->skc_obj_total = 0;
|
|
|
|
skc->skc_obj_alloc = 0;
|
|
|
|
skc->skc_obj_max = 0;
|
2012-10-30 03:51:59 +04:00
|
|
|
skc->skc_obj_deadlock = 0;
|
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-08 03:59:50 +04:00
|
|
|
skc->skc_obj_emergency = 0;
|
|
|
|
skc->skc_obj_emergency_max = 0;
|
2008-07-01 07:28:54 +04:00
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
/*
|
|
|
|
* Verify the requested alignment restriction is sane.
|
|
|
|
*/
|
2009-01-26 20:02:04 +03:00
|
|
|
if (align) {
|
2009-11-13 22:12:43 +03:00
|
|
|
VERIFY(ISP2(align));
|
2013-12-09 02:01:45 +04:00
|
|
|
VERIFY3U(align, >=, SPL_KMEM_CACHE_ALIGN);
|
|
|
|
VERIFY3U(align, <=, PAGE_SIZE);
|
2009-01-26 20:02:04 +03:00
|
|
|
skc->skc_obj_align = align;
|
|
|
|
}
|
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
/*
|
|
|
|
* When no specific type of slab is requested (kmem, vmem, or
|
|
|
|
* linuxslab) then select a cache type based on the object size
|
|
|
|
* and default tunables.
|
|
|
|
*/
|
|
|
|
if (!(skc->skc_flags & (KMC_KMEM | KMC_VMEM | KMC_SLAB))) {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Objects smaller than spl_kmem_cache_slab_limit can
|
|
|
|
* use the Linux slab for better space-efficiency. By
|
|
|
|
* default this functionality is disabled until its
|
|
|
|
* performance characters are fully understood.
|
|
|
|
*/
|
|
|
|
if (spl_kmem_cache_slab_limit &&
|
|
|
|
size <= (size_t)spl_kmem_cache_slab_limit)
|
|
|
|
skc->skc_flags |= KMC_SLAB;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Small objects, less than spl_kmem_cache_kmem_limit per
|
|
|
|
* object should use kmem because their slabs are small.
|
|
|
|
*/
|
|
|
|
else if (spl_obj_size(skc) <= spl_kmem_cache_kmem_limit)
|
2008-07-01 07:28:54 +04:00
|
|
|
skc->skc_flags |= KMC_KMEM;
|
2013-12-09 02:01:45 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* All other objects are considered large and are placed
|
|
|
|
* on vmem backed slabs.
|
|
|
|
*/
|
2009-11-13 22:12:43 +03:00
|
|
|
else
|
2008-07-01 07:28:54 +04:00
|
|
|
skc->skc_flags |= KMC_VMEM;
|
|
|
|
}
|
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
/*
|
|
|
|
* Given the type of slab allocate the required resources.
|
|
|
|
*/
|
|
|
|
if (skc->skc_flags & (KMC_KMEM | KMC_VMEM)) {
|
|
|
|
rc = spl_slab_size(skc,
|
|
|
|
&skc->skc_slab_objs, &skc->skc_slab_size);
|
|
|
|
if (rc)
|
|
|
|
SGOTO(out, rc);
|
|
|
|
|
|
|
|
rc = spl_magazine_create(skc);
|
|
|
|
if (rc)
|
|
|
|
SGOTO(out, rc);
|
|
|
|
} else {
|
|
|
|
skc->skc_linux_cache = kmem_cache_create(
|
|
|
|
skc->skc_name, size, align, 0, NULL);
|
|
|
|
if (skc->skc_linux_cache == NULL)
|
|
|
|
SGOTO(out, rc = ENOMEM);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
kmem_cache_set_allocflags(skc, __GFP_COMP);
|
|
|
|
skc->skc_flags |= KMC_NOMAGAZINE;
|
|
|
|
}
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2013-01-19 03:44:27 +04:00
|
|
|
if (spl_kmem_cache_expire & KMC_EXPIRE_AGE)
|
|
|
|
skc->skc_taskqid = taskq_dispatch_delay(spl_kmem_cache_taskq,
|
|
|
|
spl_cache_age, skc, TQ_SLEEP,
|
|
|
|
ddi_get_lbolt() + skc->skc_delay / 3 * HZ);
|
2009-01-31 07:54:49 +03:00
|
|
|
|
2008-06-14 03:41:06 +04:00
|
|
|
down_write(&spl_kmem_cache_sem);
|
2008-06-26 23:49:42 +04:00
|
|
|
list_add_tail(&skc->skc_list, &spl_kmem_cache_list);
|
2008-06-14 03:41:06 +04:00
|
|
|
up_write(&spl_kmem_cache_sem);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(skc);
|
2009-01-26 20:02:04 +03:00
|
|
|
out:
|
|
|
|
kmem_free(skc->skc_name, skc->skc_name_size);
|
|
|
|
kmem_free(skc, sizeof(*skc));
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(NULL);
|
2008-02-26 23:36:04 +03:00
|
|
|
}
|
2008-06-14 03:41:06 +04:00
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_create);
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2010-08-28 00:28:10 +04:00
|
|
|
/*
|
|
|
|
* Register a move callback to for cache defragmentation.
|
|
|
|
* XXX: Unimplemented but harmless to stub out for now.
|
|
|
|
*/
|
|
|
|
void
|
2012-08-01 10:00:40 +04:00
|
|
|
spl_kmem_cache_set_move(spl_kmem_cache_t *skc,
|
2010-08-28 00:28:10 +04:00
|
|
|
kmem_cbrc_t (move)(void *, void *, size_t, void *))
|
|
|
|
{
|
|
|
|
ASSERT(move != NULL);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_set_move);
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
2011-10-11 21:11:26 +04:00
|
|
|
* Destroy a cache and all objects associated with the cache.
|
2009-01-31 07:54:49 +03:00
|
|
|
*/
|
2008-06-14 03:41:06 +04:00
|
|
|
void
|
|
|
|
spl_kmem_cache_destroy(spl_kmem_cache_t *skc)
|
2008-02-26 23:36:04 +03:00
|
|
|
{
|
2009-01-31 07:54:49 +03:00
|
|
|
DECLARE_WAIT_QUEUE_HEAD(wq);
|
2012-12-10 22:53:46 +04:00
|
|
|
taskqid_t id;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2013-12-09 02:01:45 +04:00
|
|
|
ASSERT(skc->skc_flags & (KMC_KMEM | KMC_VMEM | KMC_SLAB));
|
2008-06-26 23:49:42 +04:00
|
|
|
|
|
|
|
down_write(&spl_kmem_cache_sem);
|
|
|
|
list_del_init(&skc->skc_list);
|
|
|
|
up_write(&spl_kmem_cache_sem);
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2012-12-10 22:53:46 +04:00
|
|
|
/* Cancel any and wait for any pending delayed tasks */
|
2011-10-11 20:59:02 +04:00
|
|
|
VERIFY(!test_and_set_bit(KMC_BIT_DESTROY, &skc->skc_flags));
|
2009-02-18 02:52:18 +03:00
|
|
|
|
2012-12-10 22:53:46 +04:00
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
id = skc->skc_taskqid;
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
|
|
|
taskq_cancel_id(spl_kmem_cache_taskq, id);
|
2009-01-31 07:54:49 +03:00
|
|
|
|
|
|
|
/* Wait until all current callers complete, this is mainly
|
|
|
|
* to catch the case where a low memory situation triggers a
|
|
|
|
* cache reaping action which races with this destroy. */
|
|
|
|
wait_event(wq, atomic_read(&skc->skc_ref) == 0);
|
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
if (skc->skc_flags & (KMC_KMEM | KMC_VMEM)) {
|
|
|
|
spl_magazine_destroy(skc);
|
|
|
|
spl_slab_reclaim(skc, 0, 1);
|
|
|
|
} else {
|
|
|
|
ASSERT(skc->skc_flags & KMC_SLAB);
|
|
|
|
kmem_cache_destroy(skc->skc_linux_cache);
|
|
|
|
}
|
|
|
|
|
2008-06-24 21:18:15 +04:00
|
|
|
spin_lock(&skc->skc_lock);
|
2008-05-07 00:38:28 +04:00
|
|
|
|
2008-06-14 03:41:06 +04:00
|
|
|
/* Validate there are no objects in use and free all the
|
2008-06-26 00:57:45 +04:00
|
|
|
* spl_kmem_slab_t, spl_kmem_obj_t, and object buffers. */
|
2009-01-31 07:54:49 +03:00
|
|
|
ASSERT3U(skc->skc_slab_alloc, ==, 0);
|
|
|
|
ASSERT3U(skc->skc_obj_alloc, ==, 0);
|
|
|
|
ASSERT3U(skc->skc_slab_total, ==, 0);
|
|
|
|
ASSERT3U(skc->skc_obj_total, ==, 0);
|
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-08 03:59:50 +04:00
|
|
|
ASSERT3U(skc->skc_obj_emergency, ==, 0);
|
2008-06-14 03:41:06 +04:00
|
|
|
ASSERT(list_empty(&skc->skc_complete_list));
|
2008-07-01 07:28:54 +04:00
|
|
|
|
2008-06-14 03:41:06 +04:00
|
|
|
kmem_free(skc->skc_name, skc->skc_name_size);
|
2008-06-24 21:18:15 +04:00
|
|
|
spin_unlock(&skc->skc_lock);
|
2008-06-28 01:40:11 +04:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
kmem_free(skc, sizeof(*skc));
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-02-26 23:36:04 +03:00
|
|
|
}
|
2008-06-14 03:41:06 +04:00
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_destroy);
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Allocate an object from a slab attached to the cache. This is used to
|
|
|
|
* repopulate the per-cpu magazine caches in batches when they run low.
|
|
|
|
*/
|
2008-06-26 00:57:45 +04:00
|
|
|
static void *
|
|
|
|
spl_cache_obj(spl_kmem_cache_t *skc, spl_kmem_slab_t *sks)
|
2008-02-26 23:36:04 +03:00
|
|
|
{
|
2008-06-14 03:41:06 +04:00
|
|
|
spl_kmem_obj_t *sko;
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
|
|
|
ASSERT(sks->sks_magic == SKS_MAGIC);
|
2008-06-26 00:57:45 +04:00
|
|
|
ASSERT(spin_is_locked(&skc->skc_lock));
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
sko = list_entry(sks->sks_free_list.next, spl_kmem_obj_t, sko_list);
|
2008-06-26 00:57:45 +04:00
|
|
|
ASSERT(sko->sko_magic == SKO_MAGIC);
|
|
|
|
ASSERT(sko->sko_addr != NULL);
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
/* Remove from sks_free_list */
|
2008-06-26 00:57:45 +04:00
|
|
|
list_del_init(&sko->sko_list);
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
sks->sks_age = jiffies;
|
|
|
|
sks->sks_ref++;
|
|
|
|
skc->skc_obj_alloc++;
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
/* Track max obj usage statistics */
|
|
|
|
if (skc->skc_obj_alloc > skc->skc_obj_max)
|
|
|
|
skc->skc_obj_max = skc->skc_obj_alloc;
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
/* Track max slab usage statistics */
|
|
|
|
if (sks->sks_ref == 1) {
|
|
|
|
skc->skc_slab_alloc++;
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
if (skc->skc_slab_alloc > skc->skc_slab_max)
|
|
|
|
skc->skc_slab_max = skc->skc_slab_alloc;
|
2008-06-14 03:41:06 +04:00
|
|
|
}
|
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
return sko->sko_addr;
|
|
|
|
}
|
2008-06-04 10:00:46 +04:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
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-08 03:59:50 +04:00
|
|
|
* Generic slab allocation function to run by the global work queues.
|
|
|
|
* It is responsible for allocating a new slab, linking it in to the list
|
|
|
|
* of partial slabs, and then waking any waiters.
|
2008-06-26 00:57:45 +04:00
|
|
|
*/
|
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-08 03:59:50 +04:00
|
|
|
static void
|
|
|
|
spl_cache_grow_work(void *data)
|
2008-06-26 00:57:45 +04:00
|
|
|
{
|
2012-12-11 01:40:03 +04:00
|
|
|
spl_kmem_alloc_t *ska = (spl_kmem_alloc_t *)data;
|
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-08 03:59:50 +04:00
|
|
|
spl_kmem_cache_t *skc = ska->ska_cache;
|
2008-06-26 23:49:42 +04:00
|
|
|
spl_kmem_slab_t *sks;
|
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-08 03:59:50 +04:00
|
|
|
|
|
|
|
sks = spl_slab_alloc(skc, ska->ska_flags | __GFP_NORETRY | KM_NODEBUG);
|
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
if (sks) {
|
|
|
|
skc->skc_slab_total++;
|
|
|
|
skc->skc_obj_total += sks->sks_objs;
|
|
|
|
list_add_tail(&sks->sks_list, &skc->skc_partial_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
atomic_dec(&skc->skc_ref);
|
|
|
|
clear_bit(KMC_BIT_GROWING, &skc->skc_flags);
|
2012-10-30 03:51:59 +04:00
|
|
|
clear_bit(KMC_BIT_DEADLOCKED, &skc->skc_flags);
|
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-08 03:59:50 +04:00
|
|
|
wake_up_all(&skc->skc_waitq);
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
|
|
|
kfree(ska);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns non-zero when a new slab should be available.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
spl_cache_grow_wait(spl_kmem_cache_t *skc)
|
|
|
|
{
|
|
|
|
return !test_bit(KMC_BIT_GROWING, &skc->skc_flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-12-09 02:01:45 +04:00
|
|
|
* No available objects on any slabs, create a new slab. Note that this
|
|
|
|
* functionality is disabled for KMC_SLAB caches which are backed by the
|
|
|
|
* Linux slab.
|
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-08 03:59:50 +04:00
|
|
|
*/
|
|
|
|
static int
|
|
|
|
spl_cache_grow(spl_kmem_cache_t *skc, int flags, void **obj)
|
|
|
|
{
|
2012-10-30 03:51:59 +04:00
|
|
|
int remaining, rc;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2013-12-09 02:01:45 +04:00
|
|
|
ASSERT((skc->skc_flags & KMC_SLAB) == 0);
|
2009-01-31 07:54:49 +03:00
|
|
|
might_sleep();
|
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-08 03:59:50 +04:00
|
|
|
*obj = NULL;
|
2008-06-26 23:49:42 +04:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
2012-11-06 01:54:20 +04:00
|
|
|
* Before allocating a new slab wait for any reaping to complete and
|
|
|
|
* then return so the local magazine can be rechecked for new objects.
|
2009-01-31 07:54:49 +03:00
|
|
|
*/
|
2012-11-06 01:54:20 +04:00
|
|
|
if (test_bit(KMC_BIT_REAPING, &skc->skc_flags)) {
|
2014-08-09 04:41:22 +04:00
|
|
|
rc = spl_wait_on_bit(&skc->skc_flags, KMC_BIT_REAPING,
|
|
|
|
TASK_UNINTERRUPTIBLE);
|
2012-11-06 01:54:20 +04:00
|
|
|
SRETURN(rc ? rc : -EAGAIN);
|
|
|
|
}
|
2008-06-14 03:41:06 +04:00
|
|
|
|
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-08 03:59:50 +04:00
|
|
|
/*
|
|
|
|
* This is handled by dispatching a work request to the global work
|
|
|
|
* queue. This allows us to asynchronously allocate a new slab while
|
|
|
|
* retaining the ability to safely fall back to a smaller synchronous
|
|
|
|
* allocations to ensure forward progress is always maintained.
|
|
|
|
*/
|
|
|
|
if (test_and_set_bit(KMC_BIT_GROWING, &skc->skc_flags) == 0) {
|
|
|
|
spl_kmem_alloc_t *ska;
|
2008-06-26 00:57:45 +04:00
|
|
|
|
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-08 03:59:50 +04:00
|
|
|
ska = kmalloc(sizeof(*ska), flags);
|
|
|
|
if (ska == NULL) {
|
|
|
|
clear_bit(KMC_BIT_GROWING, &skc->skc_flags);
|
|
|
|
wake_up_all(&skc->skc_waitq);
|
|
|
|
SRETURN(-ENOMEM);
|
|
|
|
}
|
2008-06-26 00:57:45 +04:00
|
|
|
|
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-08 03:59:50 +04:00
|
|
|
atomic_inc(&skc->skc_ref);
|
|
|
|
ska->ska_cache = skc;
|
2012-11-27 04:52:28 +04:00
|
|
|
ska->ska_flags = flags & ~__GFP_FS;
|
2012-12-11 01:40:03 +04:00
|
|
|
taskq_init_ent(&ska->ska_tqe);
|
|
|
|
taskq_dispatch_ent(spl_kmem_cache_taskq,
|
|
|
|
spl_cache_grow_work, ska, 0, &ska->ska_tqe);
|
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-08 03:59:50 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2012-10-30 03:51:59 +04:00
|
|
|
* The goal here is to only detect the rare case where a virtual slab
|
|
|
|
* allocation has deadlocked. We must be careful to minimize the use
|
|
|
|
* of emergency objects which are more expensive to track. Therefore,
|
|
|
|
* we set a very long timeout for the asynchronous allocation and if
|
|
|
|
* the timeout is reached the cache is flagged as deadlocked. From
|
|
|
|
* this point only new emergency objects will be allocated until the
|
|
|
|
* asynchronous allocation completes and clears the deadlocked flag.
|
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-08 03:59:50 +04:00
|
|
|
*/
|
2012-10-30 03:51:59 +04:00
|
|
|
if (test_bit(KMC_BIT_DEADLOCKED, &skc->skc_flags)) {
|
|
|
|
rc = spl_emergency_alloc(skc, flags, obj);
|
|
|
|
} else {
|
|
|
|
remaining = wait_event_timeout(skc->skc_waitq,
|
|
|
|
spl_cache_grow_wait(skc), HZ);
|
|
|
|
|
|
|
|
if (!remaining && test_bit(KMC_BIT_VMEM, &skc->skc_flags)) {
|
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
if (test_bit(KMC_BIT_GROWING, &skc->skc_flags)) {
|
|
|
|
set_bit(KMC_BIT_DEADLOCKED, &skc->skc_flags);
|
|
|
|
skc->skc_obj_deadlock++;
|
|
|
|
}
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
}
|
2012-09-08 01:24:17 +04:00
|
|
|
|
2012-10-30 03:51:59 +04:00
|
|
|
rc = -ENOMEM;
|
2012-09-08 01:24:17 +04:00
|
|
|
}
|
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-08 03:59:50 +04:00
|
|
|
|
|
|
|
SRETURN(rc);
|
2008-02-26 23:36:04 +03:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
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-08 03:59:50 +04:00
|
|
|
* Refill a per-cpu magazine with objects from the slabs for this cache.
|
|
|
|
* Ideally the magazine can be repopulated using existing objects which have
|
|
|
|
* been released, however if we are unable to locate enough free objects new
|
|
|
|
* slabs of objects will be created. On success NULL is returned, otherwise
|
|
|
|
* the address of a single emergency object is returned for use by the caller.
|
2009-01-31 07:54:49 +03:00
|
|
|
*/
|
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-08 03:59:50 +04:00
|
|
|
static void *
|
2008-06-26 00:57:45 +04:00
|
|
|
spl_cache_refill(spl_kmem_cache_t *skc, spl_kmem_magazine_t *skm, int flags)
|
2008-02-26 23:36:04 +03:00
|
|
|
{
|
2008-06-26 23:49:42 +04:00
|
|
|
spl_kmem_slab_t *sks;
|
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-08 03:59:50 +04:00
|
|
|
int count = 0, rc, refill;
|
|
|
|
void *obj = NULL;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
|
|
|
ASSERT(skm->skm_magic == SKM_MAGIC);
|
|
|
|
|
|
|
|
refill = MIN(skm->skm_refill, skm->skm_size - skm->skm_avail);
|
2008-06-24 21:18:15 +04:00
|
|
|
spin_lock(&skc->skc_lock);
|
2008-06-28 01:40:11 +04:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
while (refill > 0) {
|
2009-01-31 07:54:49 +03:00
|
|
|
/* No slabs available we may need to grow the cache */
|
2008-06-26 00:57:45 +04:00
|
|
|
if (list_empty(&skc->skc_partial_list)) {
|
|
|
|
spin_unlock(&skc->skc_lock);
|
2008-06-28 01:40:11 +04:00
|
|
|
|
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-08 03:59:50 +04:00
|
|
|
local_irq_enable();
|
|
|
|
rc = spl_cache_grow(skc, flags, &obj);
|
|
|
|
local_irq_disable();
|
|
|
|
|
|
|
|
/* Emergency object for immediate use by caller */
|
|
|
|
if (rc == 0 && obj != NULL)
|
|
|
|
SRETURN(obj);
|
|
|
|
|
|
|
|
if (rc)
|
2010-07-20 22:55:37 +04:00
|
|
|
SGOTO(out, rc);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
|
|
|
/* Rescheduled to different CPU skm is not local */
|
|
|
|
if (skm != skc->skc_mag[smp_processor_id()])
|
2010-07-20 22:55:37 +04:00
|
|
|
SGOTO(out, rc);
|
2008-06-26 23:49:42 +04:00
|
|
|
|
|
|
|
/* Potentially rescheduled to the same CPU but
|
2011-10-11 21:11:26 +04:00
|
|
|
* allocations may have occurred from this CPU while
|
2008-06-26 23:49:42 +04:00
|
|
|
* we were sleeping so recalculate max refill. */
|
|
|
|
refill = MIN(refill, skm->skm_size - skm->skm_avail);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
continue;
|
|
|
|
}
|
2008-06-24 21:18:15 +04:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
/* Grab the next available slab */
|
|
|
|
sks = list_entry((&skc->skc_partial_list)->next,
|
|
|
|
spl_kmem_slab_t, sks_list);
|
|
|
|
ASSERT(sks->sks_magic == SKS_MAGIC);
|
|
|
|
ASSERT(sks->sks_ref < sks->sks_objs);
|
|
|
|
ASSERT(!list_empty(&sks->sks_free_list));
|
2008-06-24 21:18:15 +04:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
/* Consume as many objects as needed to refill the requested
|
2008-06-26 23:49:42 +04:00
|
|
|
* cache. We must also be careful not to overfill it. */
|
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-08 03:59:50 +04:00
|
|
|
while (sks->sks_ref < sks->sks_objs && refill-- > 0 && ++count) {
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERT(skm->skm_avail < skm->skm_size);
|
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-08 03:59:50 +04:00
|
|
|
ASSERT(count < skm->skm_size);
|
2008-06-26 00:57:45 +04:00
|
|
|
skm->skm_objs[skm->skm_avail++]=spl_cache_obj(skc,sks);
|
2008-06-26 23:49:42 +04:00
|
|
|
}
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
/* Move slab to skc_complete_list when full */
|
|
|
|
if (sks->sks_ref == sks->sks_objs) {
|
|
|
|
list_del(&sks->sks_list);
|
|
|
|
list_add(&sks->sks_list, &skc->skc_complete_list);
|
2008-06-14 03:41:06 +04:00
|
|
|
}
|
|
|
|
}
|
2008-06-02 21:28:49 +04:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
out:
|
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-08 03:59:50 +04:00
|
|
|
SRETURN(NULL);
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Release an object back to the slab from which it came.
|
|
|
|
*/
|
2008-06-26 00:57:45 +04:00
|
|
|
static void
|
|
|
|
spl_cache_shrink(spl_kmem_cache_t *skc, void *obj)
|
|
|
|
{
|
2008-06-26 23:49:42 +04:00
|
|
|
spl_kmem_slab_t *sks = NULL;
|
2008-06-26 00:57:45 +04:00
|
|
|
spl_kmem_obj_t *sko = NULL;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2008-06-26 00:57:45 +04:00
|
|
|
ASSERT(spin_is_locked(&skc->skc_lock));
|
|
|
|
|
2009-11-13 22:12:43 +03:00
|
|
|
sko = spl_sko_from_obj(skc, obj);
|
2008-07-01 07:28:54 +04:00
|
|
|
ASSERT(sko->sko_magic == SKO_MAGIC);
|
2008-06-26 00:57:45 +04:00
|
|
|
sks = sko->sko_slab;
|
2008-07-01 07:28:54 +04:00
|
|
|
ASSERT(sks->sks_magic == SKS_MAGIC);
|
2008-06-14 03:41:06 +04:00
|
|
|
ASSERT(sks->sks_cache == skc);
|
|
|
|
list_add(&sko->sko_list, &sks->sks_free_list);
|
2008-05-07 00:38:28 +04:00
|
|
|
|
2008-06-14 03:41:06 +04:00
|
|
|
sks->sks_age = jiffies;
|
2008-06-26 00:57:45 +04:00
|
|
|
sks->sks_ref--;
|
2008-06-14 03:41:06 +04:00
|
|
|
skc->skc_obj_alloc--;
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2008-06-14 03:41:06 +04:00
|
|
|
/* Move slab to skc_partial_list when no longer full. Slabs
|
2008-06-26 00:57:45 +04:00
|
|
|
* are added to the head to keep the partial list is quasi-full
|
|
|
|
* sorted order. Fuller at the head, emptier at the tail. */
|
|
|
|
if (sks->sks_ref == (sks->sks_objs - 1)) {
|
2008-06-14 03:41:06 +04:00
|
|
|
list_del(&sks->sks_list);
|
|
|
|
list_add(&sks->sks_list, &skc->skc_partial_list);
|
|
|
|
}
|
2008-02-26 23:36:04 +03:00
|
|
|
|
2011-10-11 21:11:26 +04:00
|
|
|
/* Move empty slabs to the end of the partial list so
|
2008-06-26 00:57:45 +04:00
|
|
|
* they can be easily found and freed during reclamation. */
|
|
|
|
if (sks->sks_ref == 0) {
|
2008-06-14 03:41:06 +04:00
|
|
|
list_del(&sks->sks_list);
|
|
|
|
list_add_tail(&sks->sks_list, &skc->skc_partial_list);
|
|
|
|
skc->skc_slab_alloc--;
|
|
|
|
}
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Allocate an object from the per-cpu magazine, or if the magazine
|
|
|
|
* is empty directly allocate from a slab and repopulate the magazine.
|
|
|
|
*/
|
2008-06-26 00:57:45 +04:00
|
|
|
void *
|
|
|
|
spl_kmem_cache_alloc(spl_kmem_cache_t *skc, int flags)
|
|
|
|
{
|
|
|
|
spl_kmem_magazine_t *skm;
|
|
|
|
void *obj = NULL;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2009-01-31 07:54:49 +03:00
|
|
|
ASSERT(!test_bit(KMC_BIT_DESTROY, &skc->skc_flags));
|
|
|
|
ASSERT(flags & KM_SLEEP);
|
2013-12-09 02:01:45 +04:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
atomic_inc(&skc->skc_ref);
|
2013-12-09 02:01:45 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate directly from a Linux slab. All optimizations are left
|
|
|
|
* to the underlying cache we only need to guarantee that KM_SLEEP
|
|
|
|
* callers will never fail.
|
|
|
|
*/
|
|
|
|
if (skc->skc_flags & KMC_SLAB) {
|
|
|
|
struct kmem_cache *slc = skc->skc_linux_cache;
|
|
|
|
|
|
|
|
do {
|
|
|
|
obj = kmem_cache_alloc(slc, flags | __GFP_COMP);
|
|
|
|
if (obj && skc->skc_ctor)
|
|
|
|
skc->skc_ctor(obj, skc->skc_private, flags);
|
|
|
|
|
|
|
|
} while ((obj == NULL) && !(flags & KM_NOSLEEP));
|
|
|
|
|
|
|
|
atomic_dec(&skc->skc_ref);
|
|
|
|
SRETURN(obj);
|
|
|
|
}
|
|
|
|
|
2013-09-26 01:52:29 +04:00
|
|
|
local_irq_disable();
|
2008-06-26 00:57:45 +04:00
|
|
|
|
|
|
|
restart:
|
|
|
|
/* Safe to update per-cpu structure without lock, but
|
2011-10-11 21:11:26 +04:00
|
|
|
* in the restart case we must be careful to reacquire
|
2008-06-26 00:57:45 +04:00
|
|
|
* the local magazine since this may have changed
|
|
|
|
* when we need to grow the cache. */
|
|
|
|
skm = skc->skc_mag[smp_processor_id()];
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERTF(skm->skm_magic == SKM_MAGIC, "%x != %x: %s/%p/%p %x/%x/%x\n",
|
|
|
|
skm->skm_magic, SKM_MAGIC, skc->skc_name, skc, skm,
|
|
|
|
skm->skm_size, skm->skm_refill, skm->skm_avail);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
|
|
|
if (likely(skm->skm_avail)) {
|
|
|
|
/* Object available in CPU cache, use it */
|
|
|
|
obj = skm->skm_objs[--skm->skm_avail];
|
2009-01-31 07:54:49 +03:00
|
|
|
skm->skm_age = jiffies;
|
2008-06-26 00:57:45 +04:00
|
|
|
} else {
|
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-08 03:59:50 +04:00
|
|
|
obj = spl_cache_refill(skc, skm, flags);
|
|
|
|
if (obj == NULL)
|
|
|
|
SGOTO(restart, obj = NULL);
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
|
2013-09-26 01:52:29 +04:00
|
|
|
local_irq_enable();
|
2008-06-28 09:04:46 +04:00
|
|
|
ASSERT(obj);
|
2009-11-13 22:12:43 +03:00
|
|
|
ASSERT(IS_P2ALIGNED(obj, skc->skc_obj_align));
|
2008-06-26 00:57:45 +04:00
|
|
|
|
|
|
|
/* Pre-emptively migrate object to CPU L1 cache */
|
|
|
|
prefetchw(obj);
|
2009-01-31 07:54:49 +03:00
|
|
|
atomic_dec(&skc->skc_ref);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(obj);
|
2008-06-26 00:57:45 +04:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_alloc);
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Free an object back to the local per-cpu magazine, there is no
|
|
|
|
* guarantee that this is the same magazine the object was originally
|
|
|
|
* allocated from. We may need to flush entire from the magazine
|
|
|
|
* back to the slabs to make space.
|
|
|
|
*/
|
2008-06-26 00:57:45 +04:00
|
|
|
void
|
|
|
|
spl_kmem_cache_free(spl_kmem_cache_t *skc, void *obj)
|
|
|
|
{
|
|
|
|
spl_kmem_magazine_t *skm;
|
|
|
|
unsigned long flags;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2009-01-31 07:54:49 +03:00
|
|
|
ASSERT(!test_bit(KMC_BIT_DESTROY, &skc->skc_flags));
|
|
|
|
atomic_inc(&skc->skc_ref);
|
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-08 03:59:50 +04:00
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
/*
|
|
|
|
* Free the object from the Linux underlying Linux slab.
|
|
|
|
*/
|
|
|
|
if (skc->skc_flags & KMC_SLAB) {
|
|
|
|
if (skc->skc_dtor)
|
|
|
|
skc->skc_dtor(obj, skc->skc_private);
|
|
|
|
|
|
|
|
kmem_cache_free(skc->skc_linux_cache, obj);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
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-08 03:59:50 +04:00
|
|
|
/*
|
2012-10-30 22:21:42 +04:00
|
|
|
* Only virtual slabs may have emergency objects and these objects
|
|
|
|
* are guaranteed to have physical addresses. They must be removed
|
|
|
|
* from the tree of emergency objects and the freed.
|
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-08 03:59:50 +04:00
|
|
|
*/
|
2012-10-30 22:21:42 +04:00
|
|
|
if ((skc->skc_flags & KMC_VMEM) && !kmem_virt(obj))
|
|
|
|
SGOTO(out, spl_emergency_free(skc, obj));
|
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-08 03:59:50 +04:00
|
|
|
|
2008-06-26 00:57:45 +04:00
|
|
|
local_irq_save(flags);
|
|
|
|
|
|
|
|
/* Safe to update per-cpu structure without lock, but
|
|
|
|
* no remote memory allocation tracking is being performed
|
|
|
|
* it is entirely possible to allocate an object from one
|
|
|
|
* CPU cache and return it to another. */
|
|
|
|
skm = skc->skc_mag[smp_processor_id()];
|
2008-06-26 23:49:42 +04:00
|
|
|
ASSERT(skm->skm_magic == SKM_MAGIC);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
|
|
|
/* Per-CPU cache full, flush it to make space */
|
|
|
|
if (unlikely(skm->skm_avail >= skm->skm_size))
|
2013-01-12 02:29:32 +04:00
|
|
|
spl_cache_flush(skc, skm, skm->skm_refill);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
|
|
|
/* Available space in cache, use it */
|
|
|
|
skm->skm_objs[skm->skm_avail++] = obj;
|
|
|
|
|
|
|
|
local_irq_restore(flags);
|
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-08 03:59:50 +04:00
|
|
|
out:
|
2009-01-31 07:54:49 +03:00
|
|
|
atomic_dec(&skc->skc_ref);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-02-26 23:36:04 +03:00
|
|
|
}
|
2008-06-14 03:41:06 +04:00
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_free);
|
2008-05-10 01:21:33 +04:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
2011-10-11 21:11:26 +04:00
|
|
|
* The generic shrinker function for all caches. Under Linux a shrinker
|
|
|
|
* may not be tightly coupled with a slab cache. In fact Linux always
|
|
|
|
* systematically tries calling all registered shrinker callbacks which
|
2009-01-31 07:54:49 +03:00
|
|
|
* report that they contain unused objects. Because of this we only
|
|
|
|
* register one shrinker function in the shim layer for all slab caches.
|
|
|
|
* We always attempt to shrink all caches when this generic shrinker
|
2014-10-02 16:40:05 +04:00
|
|
|
* is called.
|
|
|
|
*
|
|
|
|
* If sc->nr_to_scan is zero, the caller is requesting a query of the
|
|
|
|
* number of objects which can potentially be freed. If it is nonzero,
|
|
|
|
* the request is to free that many objects.
|
|
|
|
*
|
|
|
|
* Linux kernels >= 3.12 have the count_objects and scan_objects callbacks
|
|
|
|
* in struct shrinker and also require the shrinker to return the number
|
|
|
|
* of objects freed.
|
|
|
|
*
|
|
|
|
* Older kernels require the shrinker to return the number of freeable
|
|
|
|
* objects following the freeing of nr_to_free.
|
|
|
|
*
|
|
|
|
* Linux semantics differ from those under Solaris, which are to
|
|
|
|
* free all available objects which may (and probably will) be more
|
|
|
|
* objects than the requested nr_to_scan.
|
2009-01-31 07:54:49 +03:00
|
|
|
*/
|
2014-10-02 16:40:05 +04:00
|
|
|
static spl_shrinker_t
|
2011-06-17 02:39:08 +04:00
|
|
|
__spl_kmem_cache_generic_shrinker(struct shrinker *shrink,
|
|
|
|
struct shrink_control *sc)
|
2008-06-14 03:41:06 +04:00
|
|
|
{
|
2008-06-26 23:49:42 +04:00
|
|
|
spl_kmem_cache_t *skc;
|
2014-05-16 20:29:21 +04:00
|
|
|
int alloc = 0;
|
2008-05-10 01:21:33 +04:00
|
|
|
|
2008-06-26 23:49:42 +04:00
|
|
|
down_read(&spl_kmem_cache_sem);
|
2009-01-31 07:54:49 +03:00
|
|
|
list_for_each_entry(skc, &spl_kmem_cache_list, skc_list) {
|
2014-10-02 16:40:05 +04:00
|
|
|
if (sc->nr_to_scan) {
|
|
|
|
#ifdef HAVE_SPLIT_SHRINKER_CALLBACK
|
|
|
|
uint64_t oldalloc = skc->skc_obj_alloc;
|
2012-04-28 02:10:02 +04:00
|
|
|
spl_kmem_cache_reap_now(skc,
|
|
|
|
MAX(sc->nr_to_scan >> fls64(skc->skc_slab_objs), 1));
|
2014-10-02 16:40:05 +04:00
|
|
|
if (oldalloc > skc->skc_obj_alloc)
|
|
|
|
alloc += oldalloc - skc->skc_obj_alloc;
|
|
|
|
#else
|
|
|
|
spl_kmem_cache_reap_now(skc,
|
|
|
|
MAX(sc->nr_to_scan >> fls64(skc->skc_slab_objs), 1));
|
|
|
|
alloc += skc->skc_obj_alloc;
|
|
|
|
#endif /* HAVE_SPLIT_SHRINKER_CALLBACK */
|
|
|
|
} else {
|
|
|
|
/* Request to query number of freeable objects */
|
|
|
|
alloc += skc->skc_obj_alloc;
|
|
|
|
}
|
2009-01-31 07:54:49 +03:00
|
|
|
}
|
2008-06-26 23:49:42 +04:00
|
|
|
up_read(&spl_kmem_cache_sem);
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2013-07-24 02:52:11 +04:00
|
|
|
/*
|
2014-05-16 20:29:21 +04:00
|
|
|
* When KMC_RECLAIM_ONCE is set allow only a single reclaim pass.
|
|
|
|
* This functionality only exists to work around a rare issue where
|
|
|
|
* shrink_slabs() is repeatedly invoked by many cores causing the
|
|
|
|
* system to thrash.
|
2013-07-24 02:52:11 +04:00
|
|
|
*/
|
2014-05-16 20:29:21 +04:00
|
|
|
if ((spl_kmem_cache_reclaim & KMC_RECLAIM_ONCE) && sc->nr_to_scan)
|
2014-10-02 16:40:05 +04:00
|
|
|
return (SHRINK_STOP);
|
2013-07-24 02:52:11 +04:00
|
|
|
|
2014-09-30 22:51:53 +04:00
|
|
|
return (MAX(alloc, 0));
|
2008-05-10 01:21:33 +04:00
|
|
|
}
|
|
|
|
|
2011-06-17 02:39:08 +04:00
|
|
|
SPL_SHRINKER_CALLBACK_WRAPPER(spl_kmem_cache_generic_shrinker);
|
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Call the registered reclaim function for a cache. Depending on how
|
|
|
|
* many and which objects are released it may simply repopulate the
|
|
|
|
* local magazine which will then need to age-out. Objects which cannot
|
|
|
|
* fit in the magazine we will be released back to their slabs which will
|
|
|
|
* also need to age out before being release. This is all just best
|
|
|
|
* effort and we do not want to thrash creating and destroying slabs.
|
|
|
|
*/
|
2008-06-02 21:28:49 +04:00
|
|
|
void
|
2012-04-28 02:10:02 +04:00
|
|
|
spl_kmem_cache_reap_now(spl_kmem_cache_t *skc, int count)
|
2008-06-02 21:28:49 +04:00
|
|
|
{
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-26 23:49:42 +04:00
|
|
|
|
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2009-01-31 07:54:49 +03:00
|
|
|
ASSERT(!test_bit(KMC_BIT_DESTROY, &skc->skc_flags));
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
atomic_inc(&skc->skc_ref);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Execute the registered reclaim callback if it exists. The
|
|
|
|
* per-cpu caches will be drained when is set KMC_EXPIRE_MEM.
|
|
|
|
*/
|
|
|
|
if (skc->skc_flags & KMC_SLAB) {
|
|
|
|
if (skc->skc_reclaim)
|
|
|
|
skc->skc_reclaim(skc->skc_private);
|
|
|
|
|
|
|
|
if (spl_kmem_cache_expire & KMC_EXPIRE_MEM)
|
|
|
|
kmem_cache_shrink(skc->skc_linux_cache);
|
|
|
|
|
|
|
|
SGOTO(out, 0);
|
2009-01-31 07:54:49 +03:00
|
|
|
}
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2013-12-09 02:01:45 +04:00
|
|
|
/*
|
|
|
|
* Prevent concurrent cache reaping when contended.
|
|
|
|
*/
|
|
|
|
if (test_and_set_bit(KMC_BIT_REAPING, &skc->skc_flags))
|
|
|
|
SGOTO(out, 0);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2012-05-02 01:27:29 +04:00
|
|
|
/*
|
|
|
|
* When a reclaim function is available it may be invoked repeatedly
|
|
|
|
* until at least a single slab can be freed. This ensures that we
|
|
|
|
* do free memory back to the system. This helps minimize the chance
|
|
|
|
* of an OOM event when the bulk of memory is used by the slab.
|
|
|
|
*
|
|
|
|
* When free slabs are already available the reclaim callback will be
|
|
|
|
* skipped. Additionally, if no forward progress is detected despite
|
|
|
|
* a reclaim function the cache will be skipped to avoid deadlock.
|
|
|
|
*
|
|
|
|
* Longer term this would be the correct place to add the code which
|
|
|
|
* repacks the slabs in order minimize fragmentation.
|
|
|
|
*/
|
|
|
|
if (skc->skc_reclaim) {
|
|
|
|
uint64_t objects = UINT64_MAX;
|
|
|
|
int do_reclaim;
|
|
|
|
|
|
|
|
do {
|
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
do_reclaim =
|
|
|
|
(skc->skc_slab_total > 0) &&
|
|
|
|
((skc->skc_slab_total - skc->skc_slab_alloc) == 0) &&
|
|
|
|
(skc->skc_obj_alloc < objects);
|
|
|
|
|
|
|
|
objects = skc->skc_obj_alloc;
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
|
|
|
if (do_reclaim)
|
|
|
|
skc->skc_reclaim(skc->skc_private);
|
|
|
|
|
|
|
|
} while (do_reclaim);
|
|
|
|
}
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2013-01-19 03:44:27 +04:00
|
|
|
/* Reclaim from the magazine then the slabs ignoring age and delay. */
|
|
|
|
if (spl_kmem_cache_expire & KMC_EXPIRE_MEM) {
|
|
|
|
spl_kmem_magazine_t *skm;
|
2013-08-05 03:35:08 +04:00
|
|
|
unsigned long irq_flags;
|
2013-01-19 03:44:27 +04:00
|
|
|
|
2013-08-05 03:35:08 +04:00
|
|
|
local_irq_save(irq_flags);
|
|
|
|
skm = skc->skc_mag[smp_processor_id()];
|
|
|
|
spl_cache_flush(skc, skm, skm->skm_avail);
|
|
|
|
local_irq_restore(irq_flags);
|
2013-01-19 03:44:27 +04:00
|
|
|
}
|
|
|
|
|
2012-04-27 23:43:49 +04:00
|
|
|
spl_slab_reclaim(skc, count, 1);
|
2009-01-31 07:54:49 +03:00
|
|
|
clear_bit(KMC_BIT_REAPING, &skc->skc_flags);
|
2014-09-14 19:47:22 +04:00
|
|
|
smp_wmb();
|
2012-11-06 01:54:20 +04:00
|
|
|
wake_up_bit(&skc->skc_flags, KMC_BIT_REAPING);
|
2013-12-09 02:01:45 +04:00
|
|
|
out:
|
2009-01-31 07:54:49 +03:00
|
|
|
atomic_dec(&skc->skc_ref);
|
2008-06-26 00:57:45 +04:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-06-02 21:28:49 +04:00
|
|
|
}
|
2008-06-14 03:41:06 +04:00
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_reap_now);
|
2008-06-02 21:28:49 +04:00
|
|
|
|
2009-01-31 07:54:49 +03:00
|
|
|
/*
|
|
|
|
* Reap all free slabs from all registered caches.
|
|
|
|
*/
|
2008-02-27 22:09:51 +03:00
|
|
|
void
|
2008-06-14 03:41:06 +04:00
|
|
|
spl_kmem_reap(void)
|
2008-04-21 21:29:47 +04:00
|
|
|
{
|
2011-06-17 02:39:08 +04:00
|
|
|
struct shrink_control sc;
|
|
|
|
|
|
|
|
sc.nr_to_scan = KMC_REAP_CHUNK;
|
|
|
|
sc.gfp_mask = GFP_KERNEL;
|
|
|
|
|
2014-10-02 16:40:05 +04:00
|
|
|
(void) __spl_kmem_cache_generic_shrinker(NULL, &sc);
|
2008-02-26 23:36:04 +03:00
|
|
|
}
|
2008-06-14 03:41:06 +04:00
|
|
|
EXPORT_SYMBOL(spl_kmem_reap);
|
2008-03-18 07:56:43 +03:00
|
|
|
|
2008-06-28 01:40:11 +04:00
|
|
|
#if defined(DEBUG_KMEM) && defined(DEBUG_KMEM_TRACKING)
|
2008-05-10 02:53:20 +04:00
|
|
|
static char *
|
2008-06-26 00:57:45 +04:00
|
|
|
spl_sprintf_addr(kmem_debug_t *kd, char *str, int len, int min)
|
2008-05-07 00:38:28 +04:00
|
|
|
{
|
2008-06-26 23:49:42 +04:00
|
|
|
int size = ((len - 1) < kd->kd_size) ? (len - 1) : kd->kd_size;
|
2008-05-07 00:38:28 +04:00
|
|
|
int i, flag = 1;
|
|
|
|
|
|
|
|
ASSERT(str != NULL && len >= 17);
|
2008-06-26 23:49:42 +04:00
|
|
|
memset(str, 0, len);
|
2008-05-07 00:38:28 +04:00
|
|
|
|
|
|
|
/* Check for a fully printable string, and while we are at
|
|
|
|
* it place the printable characters in the passed buffer. */
|
|
|
|
for (i = 0; i < size; i++) {
|
2008-06-26 23:49:42 +04:00
|
|
|
str[i] = ((char *)(kd->kd_addr))[i];
|
|
|
|
if (isprint(str[i])) {
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
/* Minimum number of printable characters found
|
|
|
|
* to make it worthwhile to print this as ascii. */
|
|
|
|
if (i > min)
|
|
|
|
break;
|
|
|
|
|
|
|
|
flag = 0;
|
|
|
|
break;
|
|
|
|
}
|
2008-05-07 00:38:28 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!flag) {
|
|
|
|
sprintf(str, "%02x%02x%02x%02x%02x%02x%02x%02x",
|
|
|
|
*((uint8_t *)kd->kd_addr),
|
|
|
|
*((uint8_t *)kd->kd_addr + 2),
|
|
|
|
*((uint8_t *)kd->kd_addr + 4),
|
|
|
|
*((uint8_t *)kd->kd_addr + 6),
|
|
|
|
*((uint8_t *)kd->kd_addr + 8),
|
|
|
|
*((uint8_t *)kd->kd_addr + 10),
|
|
|
|
*((uint8_t *)kd->kd_addr + 12),
|
|
|
|
*((uint8_t *)kd->kd_addr + 14));
|
|
|
|
}
|
|
|
|
|
|
|
|
return str;
|
|
|
|
}
|
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
static int
|
|
|
|
spl_kmem_init_tracking(struct list_head *list, spinlock_t *lock, int size)
|
|
|
|
{
|
|
|
|
int i;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-07-01 07:28:54 +04:00
|
|
|
|
|
|
|
spin_lock_init(lock);
|
|
|
|
INIT_LIST_HEAD(list);
|
|
|
|
|
|
|
|
for (i = 0; i < size; i++)
|
|
|
|
INIT_HLIST_HEAD(&kmem_table[i]);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(0);
|
2008-07-01 07:28:54 +04:00
|
|
|
}
|
|
|
|
|
2008-06-28 01:40:11 +04:00
|
|
|
static void
|
|
|
|
spl_kmem_fini_tracking(struct list_head *list, spinlock_t *lock)
|
2008-03-18 07:56:43 +03:00
|
|
|
{
|
2008-06-14 03:41:06 +04:00
|
|
|
unsigned long flags;
|
|
|
|
kmem_debug_t *kd;
|
|
|
|
char str[17];
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2008-06-28 01:40:11 +04:00
|
|
|
spin_lock_irqsave(lock, flags);
|
|
|
|
if (!list_empty(list))
|
2008-11-04 00:06:04 +03:00
|
|
|
printk(KERN_WARNING "%-16s %-5s %-16s %s:%s\n", "address",
|
|
|
|
"size", "data", "func", "line");
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2008-06-28 01:40:11 +04:00
|
|
|
list_for_each_entry(kd, list, kd_list)
|
2008-11-04 00:06:04 +03:00
|
|
|
printk(KERN_WARNING "%p %-5d %-16s %s:%d\n", kd->kd_addr,
|
2009-01-21 00:39:35 +03:00
|
|
|
(int)kd->kd_size, spl_sprintf_addr(kd, str, 17, 8),
|
2008-06-14 03:41:06 +04:00
|
|
|
kd->kd_func, kd->kd_line);
|
|
|
|
|
2008-06-28 01:40:11 +04:00
|
|
|
spin_unlock_irqrestore(lock, flags);
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-06-28 01:40:11 +04:00
|
|
|
}
|
|
|
|
#else /* DEBUG_KMEM && DEBUG_KMEM_TRACKING */
|
2008-07-01 07:28:54 +04:00
|
|
|
#define spl_kmem_init_tracking(list, lock, size)
|
2008-06-28 01:40:11 +04:00
|
|
|
#define spl_kmem_fini_tracking(list, lock)
|
|
|
|
#endif /* DEBUG_KMEM && DEBUG_KMEM_TRACKING */
|
|
|
|
|
2008-07-01 07:28:54 +04:00
|
|
|
int
|
|
|
|
spl_kmem_init(void)
|
|
|
|
{
|
|
|
|
int rc = 0;
|
2010-07-20 22:55:37 +04:00
|
|
|
SENTRY;
|
2008-07-01 07:28:54 +04:00
|
|
|
|
|
|
|
#ifdef DEBUG_KMEM
|
2009-12-05 02:54:12 +03:00
|
|
|
kmem_alloc_used_set(0);
|
|
|
|
vmem_alloc_used_set(0);
|
2008-07-01 07:28:54 +04:00
|
|
|
|
|
|
|
spl_kmem_init_tracking(&kmem_list, &kmem_lock, KMEM_TABLE_SIZE);
|
|
|
|
spl_kmem_init_tracking(&vmem_list, &vmem_lock, VMEM_TABLE_SIZE);
|
|
|
|
#endif
|
2013-05-31 06:52:36 +04:00
|
|
|
|
|
|
|
init_rwsem(&spl_kmem_cache_sem);
|
|
|
|
INIT_LIST_HEAD(&spl_kmem_cache_list);
|
|
|
|
spl_kmem_cache_taskq = taskq_create("spl_kmem_cache",
|
|
|
|
1, maxclsyspri, 1, 32, TASKQ_PREPOPULATE);
|
|
|
|
|
|
|
|
spl_register_shrinker(&spl_kmem_cache_shrinker);
|
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SRETURN(rc);
|
2008-07-01 07:28:54 +04:00
|
|
|
}
|
|
|
|
|
2008-06-28 01:40:11 +04:00
|
|
|
void
|
|
|
|
spl_kmem_fini(void)
|
|
|
|
{
|
2013-07-11 02:04:07 +04:00
|
|
|
SENTRY;
|
|
|
|
|
|
|
|
spl_unregister_shrinker(&spl_kmem_cache_shrinker);
|
|
|
|
taskq_destroy(spl_kmem_cache_taskq);
|
|
|
|
|
2008-06-28 01:40:11 +04:00
|
|
|
#ifdef DEBUG_KMEM
|
|
|
|
/* Display all unreclaimed memory addresses, including the
|
|
|
|
* allocation size and the first few bytes of what's located
|
|
|
|
* at that address to aid in debugging. Performance is not
|
|
|
|
* a serious concern here since it is module unload time. */
|
2009-12-05 02:54:12 +03:00
|
|
|
if (kmem_alloc_used_read() != 0)
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-06-17 02:57:04 +04:00
|
|
|
"kmem leaked %ld/%ld bytes\n",
|
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-06-28 01:40:11 +04:00
|
|
|
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2009-12-05 02:54:12 +03:00
|
|
|
if (vmem_alloc_used_read() != 0)
|
2010-07-20 22:55:37 +04:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-06-17 02:57:04 +04:00
|
|
|
"vmem leaked %ld/%ld bytes\n",
|
|
|
|
vmem_alloc_used_read(), vmem_alloc_max);
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2008-06-28 01:40:11 +04:00
|
|
|
spl_kmem_fini_tracking(&kmem_list, &kmem_lock);
|
|
|
|
spl_kmem_fini_tracking(&vmem_list, &vmem_lock);
|
|
|
|
#endif /* DEBUG_KMEM */
|
2008-06-14 03:41:06 +04:00
|
|
|
|
2010-07-20 22:55:37 +04:00
|
|
|
SEXIT;
|
2008-03-18 07:56:43 +03:00
|
|
|
}
|