2010-05-17 22:18:00 +00:00
|
|
|
/*****************************************************************************\
|
|
|
|
* Copyright (C) 2007-2010 Lawrence Livermore National Security, LLC.
|
|
|
|
* Copyright (C) 2007 The Regents of the University of California.
|
|
|
|
* Produced at Lawrence Livermore National Laboratory (cf, DISCLAIMER).
|
|
|
|
* Written by Brian Behlendorf <behlendorf1@llnl.gov>.
|
2008-05-26 04:38:26 +00:00
|
|
|
* UCRL-CODE-235197
|
|
|
|
*
|
2010-05-17 22:18:00 +00:00
|
|
|
* This file is part of the SPL, Solaris Porting Layer.
|
|
|
|
* For details, see <http://github.com/behlendorf/spl/>.
|
2008-05-26 04:38:26 +00:00
|
|
|
*
|
2010-05-17 22:18:00 +00:00
|
|
|
* The SPL is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
* Free Software Foundation; either version 2 of the License, or (at your
|
|
|
|
* option) any later version.
|
|
|
|
*
|
|
|
|
* The SPL is distributed in the hope that it will be useful, but WITHOUT
|
2008-05-26 04:38:26 +00:00
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
|
|
|
* for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2010-05-17 22:18:00 +00:00
|
|
|
* with the SPL. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*****************************************************************************
|
|
|
|
* Solaris Porting Layer (SPL) Kmem Implementation.
|
|
|
|
\*****************************************************************************/
|
2008-05-26 04:38:26 +00:00
|
|
|
|
2008-03-01 00:45:59 +00:00
|
|
|
#include <sys/kmem.h>
|
2010-07-19 21:16:05 +00:00
|
|
|
#include <spl-debug.h>
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
#ifdef SS_DEBUG_SUBSYS
|
|
|
|
#undef SS_DEBUG_SUBSYS
|
2008-04-21 17:29:47 +00:00
|
|
|
#endif
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
#define SS_DEBUG_SUBSYS SS_KMEM
|
2008-04-21 17:29:47 +00:00
|
|
|
|
2009-02-04 23:15:41 +00:00
|
|
|
/*
|
|
|
|
* The minimum amount of memory measured in pages to be free at all
|
|
|
|
* times on the system. This is similar to Linux's zone->pages_min
|
2011-10-11 17:11:26 +00:00
|
|
|
* multiplied by the number of zones and is sized based on that.
|
2009-02-04 23:15:41 +00:00
|
|
|
*/
|
|
|
|
pgcnt_t minfree = 0;
|
|
|
|
EXPORT_SYMBOL(minfree);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The desired amount of memory measured in pages to be free at all
|
|
|
|
* times on the system. This is similar to Linux's zone->pages_low
|
2011-10-11 17:11:26 +00:00
|
|
|
* multiplied by the number of zones and is sized based on that.
|
2009-02-04 23:15:41 +00:00
|
|
|
* Assuming all zones are being used roughly equally, when we drop
|
2011-10-11 17:11:26 +00:00
|
|
|
* below this threshold asynchronous page reclamation is triggered.
|
2009-02-04 23:15:41 +00:00
|
|
|
*/
|
|
|
|
pgcnt_t desfree = 0;
|
|
|
|
EXPORT_SYMBOL(desfree);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When above this amount of memory measures in pages the system is
|
|
|
|
* determined to have enough free memory. This is similar to Linux's
|
2011-10-11 17:11:26 +00:00
|
|
|
* zone->pages_high multiplied by the number of zones and is sized based
|
2009-02-04 23:15:41 +00:00
|
|
|
* on that. Assuming all zones are being used roughly equally, when
|
2011-10-11 17:11:26 +00:00
|
|
|
* asynchronous page reclamation reaches this threshold it stops.
|
2009-02-04 23:15:41 +00:00
|
|
|
*/
|
|
|
|
pgcnt_t lotsfree = 0;
|
|
|
|
EXPORT_SYMBOL(lotsfree);
|
|
|
|
|
|
|
|
/* Unused always 0 in this implementation */
|
|
|
|
pgcnt_t needfree = 0;
|
|
|
|
EXPORT_SYMBOL(needfree);
|
|
|
|
|
|
|
|
pgcnt_t swapfs_minfree = 0;
|
|
|
|
EXPORT_SYMBOL(swapfs_minfree);
|
|
|
|
|
|
|
|
pgcnt_t swapfs_reserve = 0;
|
|
|
|
EXPORT_SYMBOL(swapfs_reserve);
|
|
|
|
|
|
|
|
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-25 21:20:40 +00:00
|
|
|
#ifndef HAVE_GET_VMALLOC_INFO
|
2009-05-20 17:08:37 +00:00
|
|
|
get_vmalloc_info_t get_vmalloc_info_fn = SYMBOL_POISON;
|
2009-02-25 21:20:40 +00:00
|
|
|
EXPORT_SYMBOL(get_vmalloc_info_fn);
|
|
|
|
#endif /* HAVE_GET_VMALLOC_INFO */
|
|
|
|
|
2009-05-20 21:23:13 +00:00
|
|
|
#ifdef HAVE_PGDAT_HELPERS
|
|
|
|
# ifndef HAVE_FIRST_ONLINE_PGDAT
|
2009-05-20 17:08:37 +00:00
|
|
|
first_online_pgdat_t first_online_pgdat_fn = SYMBOL_POISON;
|
2009-02-25 21:20:40 +00:00
|
|
|
EXPORT_SYMBOL(first_online_pgdat_fn);
|
2009-05-20 21:23:13 +00:00
|
|
|
# endif /* HAVE_FIRST_ONLINE_PGDAT */
|
2009-02-04 23:15:41 +00:00
|
|
|
|
2009-05-20 21:23:13 +00:00
|
|
|
# ifndef HAVE_NEXT_ONLINE_PGDAT
|
2009-05-20 17:08:37 +00:00
|
|
|
next_online_pgdat_t next_online_pgdat_fn = SYMBOL_POISON;
|
2009-02-25 21:20:40 +00:00
|
|
|
EXPORT_SYMBOL(next_online_pgdat_fn);
|
2009-05-20 21:23:13 +00:00
|
|
|
# endif /* HAVE_NEXT_ONLINE_PGDAT */
|
2009-02-04 23:15:41 +00:00
|
|
|
|
2009-05-20 21:23:13 +00:00
|
|
|
# ifndef HAVE_NEXT_ZONE
|
2009-05-20 17:08:37 +00:00
|
|
|
next_zone_t next_zone_fn = SYMBOL_POISON;
|
2009-02-25 21:20:40 +00:00
|
|
|
EXPORT_SYMBOL(next_zone_fn);
|
2009-05-20 21:23:13 +00:00
|
|
|
# endif /* HAVE_NEXT_ZONE */
|
|
|
|
|
|
|
|
#else /* HAVE_PGDAT_HELPERS */
|
|
|
|
|
|
|
|
# ifndef HAVE_PGDAT_LIST
|
|
|
|
struct pglist_data *pgdat_list_addr = SYMBOL_POISON;
|
|
|
|
EXPORT_SYMBOL(pgdat_list_addr);
|
|
|
|
# endif /* HAVE_PGDAT_LIST */
|
|
|
|
|
|
|
|
#endif /* HAVE_PGDAT_HELPERS */
|
2009-02-04 23:15:41 +00:00
|
|
|
|
2009-07-28 22:06:42 +00:00
|
|
|
#ifdef NEED_GET_ZONE_COUNTS
|
2009-03-17 19:16:31 +00:00
|
|
|
# ifndef HAVE_GET_ZONE_COUNTS
|
2009-05-20 17:08:37 +00:00
|
|
|
get_zone_counts_t get_zone_counts_fn = SYMBOL_POISON;
|
2009-02-25 21:20:40 +00:00
|
|
|
EXPORT_SYMBOL(get_zone_counts_fn);
|
2009-05-20 17:08:37 +00:00
|
|
|
# endif /* HAVE_GET_ZONE_COUNTS */
|
2009-02-05 20:26:34 +00:00
|
|
|
|
2009-03-17 19:16:31 +00:00
|
|
|
unsigned long
|
2009-07-28 22:06:42 +00:00
|
|
|
spl_global_page_state(spl_zone_stat_item_t item)
|
2009-02-05 20:26:34 +00:00
|
|
|
{
|
|
|
|
unsigned long active;
|
|
|
|
unsigned long inactive;
|
|
|
|
unsigned long free;
|
|
|
|
|
2009-07-28 22:06:42 +00:00
|
|
|
get_zone_counts(&active, &inactive, &free);
|
|
|
|
switch (item) {
|
|
|
|
case SPL_NR_FREE_PAGES: return free;
|
|
|
|
case SPL_NR_INACTIVE: return inactive;
|
|
|
|
case SPL_NR_ACTIVE: return active;
|
|
|
|
default: ASSERT(0); /* Unsupported */
|
2009-03-17 19:16:31 +00:00
|
|
|
}
|
|
|
|
|
2009-07-28 22:06:42 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
# ifdef HAVE_GLOBAL_PAGE_STATE
|
|
|
|
unsigned long
|
|
|
|
spl_global_page_state(spl_zone_stat_item_t item)
|
|
|
|
{
|
|
|
|
unsigned long pages = 0;
|
|
|
|
|
|
|
|
switch (item) {
|
|
|
|
case SPL_NR_FREE_PAGES:
|
|
|
|
# ifdef HAVE_ZONE_STAT_ITEM_NR_FREE_PAGES
|
|
|
|
pages += global_page_state(NR_FREE_PAGES);
|
|
|
|
# endif
|
|
|
|
break;
|
|
|
|
case SPL_NR_INACTIVE:
|
|
|
|
# ifdef HAVE_ZONE_STAT_ITEM_NR_INACTIVE
|
|
|
|
pages += global_page_state(NR_INACTIVE);
|
|
|
|
# endif
|
|
|
|
# ifdef HAVE_ZONE_STAT_ITEM_NR_INACTIVE_ANON
|
|
|
|
pages += global_page_state(NR_INACTIVE_ANON);
|
|
|
|
# endif
|
|
|
|
# ifdef HAVE_ZONE_STAT_ITEM_NR_INACTIVE_FILE
|
|
|
|
pages += global_page_state(NR_INACTIVE_FILE);
|
|
|
|
# endif
|
|
|
|
break;
|
|
|
|
case SPL_NR_ACTIVE:
|
|
|
|
# ifdef HAVE_ZONE_STAT_ITEM_NR_ACTIVE
|
|
|
|
pages += global_page_state(NR_ACTIVE);
|
|
|
|
# endif
|
|
|
|
# ifdef HAVE_ZONE_STAT_ITEM_NR_ACTIVE_ANON
|
|
|
|
pages += global_page_state(NR_ACTIVE_ANON);
|
|
|
|
# endif
|
|
|
|
# ifdef HAVE_ZONE_STAT_ITEM_NR_ACTIVE_FILE
|
|
|
|
pages += global_page_state(NR_ACTIVE_FILE);
|
|
|
|
# endif
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ASSERT(0); /* Unsupported */
|
2009-03-17 19:16:31 +00:00
|
|
|
}
|
|
|
|
|
2009-07-28 22:06:42 +00:00
|
|
|
return pages;
|
|
|
|
}
|
2009-05-20 17:08:37 +00:00
|
|
|
# else
|
2009-07-28 22:06:42 +00:00
|
|
|
# error "Both global_page_state() and get_zone_counts() unavailable"
|
2009-05-20 17:08:37 +00:00
|
|
|
# endif /* HAVE_GLOBAL_PAGE_STATE */
|
2009-07-28 22:06:42 +00:00
|
|
|
#endif /* NEED_GET_ZONE_COUNTS */
|
2009-03-17 19:16:31 +00:00
|
|
|
EXPORT_SYMBOL(spl_global_page_state);
|
2009-02-05 20:26:34 +00:00
|
|
|
|
2011-12-21 22:22:45 +00:00
|
|
|
#if !defined(HAVE_INVALIDATE_INODES) && !defined(HAVE_INVALIDATE_INODES_CHECK)
|
2011-02-23 20:25:45 +00:00
|
|
|
invalidate_inodes_t invalidate_inodes_fn = SYMBOL_POISON;
|
|
|
|
EXPORT_SYMBOL(invalidate_inodes_fn);
|
2011-12-21 22:22:45 +00:00
|
|
|
#endif /* !HAVE_INVALIDATE_INODES && !HAVE_INVALIDATE_INODES_CHECK */
|
2011-02-23 20:25:45 +00:00
|
|
|
|
2011-03-31 00:44:35 +00:00
|
|
|
#ifndef HAVE_SHRINK_DCACHE_MEMORY
|
|
|
|
shrink_dcache_memory_t shrink_dcache_memory_fn = SYMBOL_POISON;
|
|
|
|
EXPORT_SYMBOL(shrink_dcache_memory_fn);
|
|
|
|
#endif /* HAVE_SHRINK_DCACHE_MEMORY */
|
|
|
|
|
|
|
|
#ifndef HAVE_SHRINK_ICACHE_MEMORY
|
|
|
|
shrink_icache_memory_t shrink_icache_memory_fn = SYMBOL_POISON;
|
|
|
|
EXPORT_SYMBOL(shrink_icache_memory_fn);
|
|
|
|
#endif /* HAVE_SHRINK_ICACHE_MEMORY */
|
|
|
|
|
2009-03-17 19:16:31 +00:00
|
|
|
pgcnt_t
|
|
|
|
spl_kmem_availrmem(void)
|
|
|
|
{
|
2009-02-05 20:26:34 +00:00
|
|
|
/* The amount of easily available memory */
|
2009-07-28 22:06:42 +00:00
|
|
|
return (spl_global_page_state(SPL_NR_FREE_PAGES) +
|
|
|
|
spl_global_page_state(SPL_NR_INACTIVE));
|
2009-02-05 20:26:34 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(spl_kmem_availrmem);
|
|
|
|
|
|
|
|
size_t
|
|
|
|
vmem_size(vmem_t *vmp, int typemask)
|
|
|
|
{
|
2009-02-25 21:20:40 +00:00
|
|
|
struct vmalloc_info vmi;
|
|
|
|
size_t size = 0;
|
|
|
|
|
2009-02-05 20:26:34 +00:00
|
|
|
ASSERT(vmp == NULL);
|
|
|
|
ASSERT(typemask & (VMEM_ALLOC | VMEM_FREE));
|
|
|
|
|
2009-02-25 21:20:40 +00:00
|
|
|
get_vmalloc_info(&vmi);
|
|
|
|
if (typemask & VMEM_ALLOC)
|
|
|
|
size += (size_t)vmi.used;
|
|
|
|
|
|
|
|
if (typemask & VMEM_FREE)
|
|
|
|
size += (size_t)(VMALLOC_TOTAL - vmi.used);
|
|
|
|
|
|
|
|
return size;
|
2009-02-05 20:26:34 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vmem_size);
|
|
|
|
|
2010-06-11 21:48:18 +00:00
|
|
|
int
|
|
|
|
kmem_debugging(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_debugging);
|
|
|
|
|
|
|
|
#ifndef HAVE_KVASPRINTF
|
|
|
|
/* Simplified asprintf. */
|
|
|
|
char *kvasprintf(gfp_t gfp, const char *fmt, va_list ap)
|
|
|
|
{
|
|
|
|
unsigned int len;
|
|
|
|
char *p;
|
|
|
|
va_list aq;
|
|
|
|
|
|
|
|
va_copy(aq, ap);
|
|
|
|
len = vsnprintf(NULL, 0, fmt, aq);
|
|
|
|
va_end(aq);
|
|
|
|
|
|
|
|
p = kmalloc(len+1, gfp);
|
|
|
|
if (!p)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
vsnprintf(p, len+1, fmt, ap);
|
|
|
|
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kvasprintf);
|
|
|
|
#endif /* HAVE_KVASPRINTF */
|
|
|
|
|
2010-06-24 16:41:59 +00:00
|
|
|
char *
|
|
|
|
kmem_vasprintf(const char *fmt, va_list ap)
|
|
|
|
{
|
|
|
|
va_list aq;
|
|
|
|
char *ptr;
|
|
|
|
|
|
|
|
do {
|
2010-07-20 20:51:42 +00:00
|
|
|
va_copy(aq, ap);
|
2010-06-24 16:41:59 +00:00
|
|
|
ptr = kvasprintf(GFP_KERNEL, fmt, aq);
|
2010-07-20 20:51:42 +00:00
|
|
|
va_end(aq);
|
2010-06-24 16:41:59 +00:00
|
|
|
} while (ptr == NULL);
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_vasprintf);
|
|
|
|
|
2010-06-11 21:48:18 +00:00
|
|
|
char *
|
|
|
|
kmem_asprintf(const char *fmt, ...)
|
|
|
|
{
|
2010-06-24 16:41:59 +00:00
|
|
|
va_list ap;
|
2010-06-11 21:48:18 +00:00
|
|
|
char *ptr;
|
|
|
|
|
|
|
|
do {
|
2010-07-20 20:51:42 +00:00
|
|
|
va_start(ap, fmt);
|
2010-06-24 16:41:59 +00:00
|
|
|
ptr = kvasprintf(GFP_KERNEL, fmt, ap);
|
2010-07-20 20:51:42 +00:00
|
|
|
va_end(ap);
|
2010-06-11 21:48:18 +00:00
|
|
|
} while (ptr == NULL);
|
|
|
|
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_asprintf);
|
|
|
|
|
2010-07-26 22:47:55 +00: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 05:20:58 +00:00
|
|
|
kfree(str);
|
2010-07-26 22:47:55 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(strfree);
|
|
|
|
|
2008-02-26 20:36:04 +00:00
|
|
|
/*
|
2008-06-13 23:41:06 +00:00
|
|
|
* Memory allocation interfaces and debugging for basic kmem_*
|
2009-10-30 20:58:51 +00: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 20:36:04 +00:00
|
|
|
*/
|
|
|
|
#ifdef DEBUG_KMEM
|
2009-12-04 23:54:12 +00:00
|
|
|
|
2008-02-26 20:36:04 +00:00
|
|
|
/* Shim layer memory accounting */
|
2009-12-04 23:54:12 +00:00
|
|
|
# ifdef HAVE_ATOMIC64_T
|
2008-11-03 20:34:17 +00:00
|
|
|
atomic64_t kmem_alloc_used = ATOMIC64_INIT(0);
|
2008-11-03 21:06:04 +00:00
|
|
|
unsigned long long kmem_alloc_max = 0;
|
2008-11-03 20:34:17 +00:00
|
|
|
atomic64_t vmem_alloc_used = ATOMIC64_INIT(0);
|
2008-11-03 21:06:04 +00:00
|
|
|
unsigned long long vmem_alloc_max = 0;
|
2010-07-26 22:47:55 +00:00
|
|
|
# else /* HAVE_ATOMIC64_T */
|
2009-12-04 23:54:12 +00: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-26 22:47:55 +00:00
|
|
|
# endif /* HAVE_ATOMIC64_T */
|
2008-03-14 19:04:41 +00:00
|
|
|
|
2008-06-27 21:40:11 +00:00
|
|
|
EXPORT_SYMBOL(kmem_alloc_used);
|
|
|
|
EXPORT_SYMBOL(kmem_alloc_max);
|
|
|
|
EXPORT_SYMBOL(vmem_alloc_used);
|
|
|
|
EXPORT_SYMBOL(vmem_alloc_max);
|
|
|
|
|
2009-10-30 20:58:51 +00: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-03 21:06:04 +00:00
|
|
|
*/
|
2009-10-30 20:58:51 +00:00
|
|
|
# ifdef DEBUG_KMEM_TRACKING
|
2008-11-03 21:06:04 +00: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-06 20:38:28 +00:00
|
|
|
spinlock_t kmem_lock;
|
|
|
|
struct hlist_head kmem_table[KMEM_TABLE_SIZE];
|
|
|
|
struct list_head kmem_list;
|
|
|
|
|
2008-05-07 18:54:32 +00:00
|
|
|
spinlock_t vmem_lock;
|
|
|
|
struct hlist_head vmem_table[VMEM_TABLE_SIZE];
|
|
|
|
struct list_head vmem_list;
|
|
|
|
|
2008-05-06 20:38:28 +00:00
|
|
|
EXPORT_SYMBOL(kmem_lock);
|
|
|
|
EXPORT_SYMBOL(kmem_table);
|
|
|
|
EXPORT_SYMBOL(kmem_list);
|
|
|
|
|
2008-05-07 18:54:32 +00:00
|
|
|
EXPORT_SYMBOL(vmem_lock);
|
|
|
|
EXPORT_SYMBOL(vmem_table);
|
|
|
|
EXPORT_SYMBOL(vmem_list);
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
static kmem_debug_t *
|
2012-06-25 17:22:21 +00:00
|
|
|
kmem_del_init(spinlock_t *lock, struct hlist_head *table, int bits, const void *addr)
|
2008-11-03 21:06:04 +00:00
|
|
|
{
|
|
|
|
struct hlist_head *head;
|
|
|
|
struct hlist_node *node;
|
|
|
|
struct kmem_debug *p;
|
|
|
|
unsigned long flags;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
spin_lock_irqsave(lock, flags);
|
|
|
|
|
|
|
|
head = &table[hash_ptr(addr, bits)];
|
|
|
|
hlist_for_each_entry_rcu(p, node, head, kd_hlist) {
|
|
|
|
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 18:55:37 +00:00
|
|
|
SRETURN(NULL);
|
2008-11-03 21:06:04 +00: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 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-11-03 21:06:04 +00:00
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
/* Function may be called with KM_NOSLEEP so failure is possible */
|
2009-11-12 23:11:24 +00:00
|
|
|
dptr = (kmem_debug_t *) kmalloc_nofail(sizeof(kmem_debug_t),
|
2008-11-03 21:06:04 +00:00
|
|
|
flags & ~__GFP_ZERO);
|
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
if (unlikely(dptr == NULL)) {
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "debug "
|
2010-06-16 22:57:04 +00: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-03 21:06:04 +00:00
|
|
|
} else {
|
2010-07-26 22:47:55 +00:00
|
|
|
/*
|
|
|
|
* Marked unlikely because we should never be doing this,
|
|
|
|
* we tolerate to up 2 pages but a single page is best.
|
|
|
|
*/
|
2010-05-20 21:16:59 +00:00
|
|
|
if (unlikely((size > PAGE_SIZE*2) && !(flags & KM_NODEBUG))) {
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "large "
|
2010-06-16 22:57:04 +00:00
|
|
|
"kmem_alloc(%llu, 0x%x) at %s:%d (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-04 23:54:12 +00:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2010-05-19 23:53:13 +00:00
|
|
|
spl_debug_dumpstack(NULL);
|
|
|
|
}
|
2008-11-03 21:06:04 +00:00
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
/*
|
|
|
|
* We use __strdup() below because the string pointed to by
|
2008-11-03 22:02:15 +00:00
|
|
|
* __FUNCTION__ might not be available by the time we want
|
2010-07-26 22:47:55 +00: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-03 22:02:15 +00:00
|
|
|
if (unlikely(dptr->kd_func == NULL)) {
|
|
|
|
kfree(dptr);
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-07-26 22:47:55 +00:00
|
|
|
"debug __strdup() at %s:%d failed (%lld/%llu)\n",
|
2010-06-16 22:57:04 +00:00
|
|
|
func, line, kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-03 22:02:15 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2008-11-03 21:06:04 +00:00
|
|
|
/* Use the correct allocator */
|
|
|
|
if (node_alloc) {
|
|
|
|
ASSERT(!(flags & __GFP_ZERO));
|
2009-11-12 23:11:24 +00:00
|
|
|
ptr = kmalloc_node_nofail(size, flags, node);
|
2008-11-03 21:06:04 +00:00
|
|
|
} else if (flags & __GFP_ZERO) {
|
2009-11-12 23:11:24 +00:00
|
|
|
ptr = kzalloc_nofail(size, flags & ~__GFP_ZERO);
|
2008-11-03 21:06:04 +00:00
|
|
|
} else {
|
2009-11-12 23:11:24 +00:00
|
|
|
ptr = kmalloc_nofail(size, flags);
|
2008-11-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (unlikely(ptr == NULL)) {
|
2008-11-03 22:02:15 +00:00
|
|
|
kfree(dptr->kd_func);
|
2008-11-03 21:06:04 +00:00
|
|
|
kfree(dptr);
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "kmem_alloc"
|
2010-06-16 22:57:04 +00:00
|
|
|
"(%llu, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-04 23:54:12 +00:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-03 21:06:04 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2009-12-04 23:54:12 +00:00
|
|
|
kmem_alloc_used_add(size);
|
|
|
|
if (unlikely(kmem_alloc_used_read() > kmem_alloc_max))
|
|
|
|
kmem_alloc_max = kmem_alloc_used_read();
|
2008-11-03 21:06:04 +00: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);
|
|
|
|
hlist_add_head_rcu(&dptr->kd_hlist,
|
|
|
|
&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 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_INFO,
|
2010-06-16 22:57:04 +00: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-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
out:
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(ptr);
|
2008-11-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_alloc_track);
|
|
|
|
|
|
|
|
void
|
2012-06-25 17:22:21 +00:00
|
|
|
kmem_free_track(const void *ptr, size_t size)
|
2008-11-03 21:06:04 +00:00
|
|
|
{
|
|
|
|
kmem_debug_t *dptr;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-11-03 21:06:04 +00: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-26 22:47:55 +00:00
|
|
|
/* Must exist in hash due to kmem_alloc() */
|
|
|
|
ASSERT(dptr);
|
2008-11-03 21:06:04 +00: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-04 23:54:12 +00:00
|
|
|
kmem_alloc_used_sub(size);
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "kmem_free(%p, %llu) (%lld/%llu)\n", ptr,
|
2009-12-04 23:54:12 +00:00
|
|
|
(unsigned long long) size, kmem_alloc_used_read(),
|
2008-11-03 21:06:04 +00:00
|
|
|
kmem_alloc_max);
|
|
|
|
|
2008-11-03 22:02:15 +00:00
|
|
|
kfree(dptr->kd_func);
|
|
|
|
|
2008-11-03 21:06:04 +00:00
|
|
|
memset(dptr, 0x5a, sizeof(kmem_debug_t));
|
|
|
|
kfree(dptr);
|
|
|
|
|
|
|
|
memset(ptr, 0x5a, size);
|
|
|
|
kfree(ptr);
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-11-03 21:06:04 +00: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 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
ASSERT(flags & KM_SLEEP);
|
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
/* Function may be called with KM_NOSLEEP so failure is possible */
|
2009-12-23 20:57:10 +00:00
|
|
|
dptr = (kmem_debug_t *) kmalloc_nofail(sizeof(kmem_debug_t),
|
|
|
|
flags & ~__GFP_ZERO);
|
2010-07-26 22:47:55 +00:00
|
|
|
if (unlikely(dptr == NULL)) {
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "debug "
|
2010-06-16 22:57:04 +00: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-03 21:06:04 +00:00
|
|
|
} else {
|
2010-07-26 22:47:55 +00:00
|
|
|
/*
|
|
|
|
* We use __strdup() below because the string pointed to by
|
2008-11-03 22:02:15 +00:00
|
|
|
* __FUNCTION__ might not be available by the time we want
|
2010-07-26 22:47:55 +00: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-03 22:02:15 +00:00
|
|
|
if (unlikely(dptr->kd_func == NULL)) {
|
|
|
|
kfree(dptr);
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-07-26 22:47:55 +00:00
|
|
|
"debug __strdup() at %s:%d failed (%lld/%llu)\n",
|
2010-06-16 22:57:04 +00:00
|
|
|
func, line, vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-03 22:02:15 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
/* Use the correct allocator */
|
|
|
|
if (flags & __GFP_ZERO) {
|
|
|
|
ptr = vzalloc_nofail(size, flags & ~__GFP_ZERO);
|
|
|
|
} else {
|
|
|
|
ptr = vmalloc_nofail(size, flags);
|
|
|
|
}
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
if (unlikely(ptr == NULL)) {
|
2008-11-03 22:02:15 +00:00
|
|
|
kfree(dptr->kd_func);
|
2008-11-03 21:06:04 +00:00
|
|
|
kfree(dptr);
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING, "vmem_alloc"
|
2010-06-16 22:57:04 +00:00
|
|
|
"(%llu, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-04 23:54:12 +00:00
|
|
|
vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-03 21:06:04 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2009-12-04 23:54:12 +00:00
|
|
|
vmem_alloc_used_add(size);
|
|
|
|
if (unlikely(vmem_alloc_used_read() > vmem_alloc_max))
|
|
|
|
vmem_alloc_max = vmem_alloc_used_read();
|
2008-11-03 21:06:04 +00: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);
|
|
|
|
hlist_add_head_rcu(&dptr->kd_hlist,
|
|
|
|
&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 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_INFO,
|
2010-06-16 22:57:04 +00: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-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
out:
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(ptr);
|
2008-11-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vmem_alloc_track);
|
|
|
|
|
|
|
|
void
|
2012-06-25 17:22:21 +00:00
|
|
|
vmem_free_track(const void *ptr, size_t size)
|
2008-11-03 21:06:04 +00:00
|
|
|
{
|
|
|
|
kmem_debug_t *dptr;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-11-03 21:06:04 +00: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-26 22:47:55 +00:00
|
|
|
|
|
|
|
/* Must exist in hash due to vmem_alloc() */
|
|
|
|
ASSERT(dptr);
|
2008-11-03 21:06:04 +00: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-04 23:54:12 +00:00
|
|
|
vmem_alloc_used_sub(size);
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "vmem_free(%p, %llu) (%lld/%llu)\n", ptr,
|
2009-12-04 23:54:12 +00:00
|
|
|
(unsigned long long) size, vmem_alloc_used_read(),
|
2008-11-03 21:06:04 +00:00
|
|
|
vmem_alloc_max);
|
|
|
|
|
2008-11-03 22:02:15 +00:00
|
|
|
kfree(dptr->kd_func);
|
|
|
|
|
2008-11-03 21:06:04 +00:00
|
|
|
memset(dptr, 0x5a, sizeof(kmem_debug_t));
|
|
|
|
kfree(dptr);
|
|
|
|
|
|
|
|
memset(ptr, 0x5a, size);
|
|
|
|
vfree(ptr);
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-11-03 21:06:04 +00: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 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-11-03 21:06:04 +00:00
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
/*
|
|
|
|
* Marked unlikely because we should never be doing this,
|
|
|
|
* we tolerate to up 2 pages but a single page is best.
|
|
|
|
*/
|
2010-05-20 21:16:59 +00:00
|
|
|
if (unlikely((size > PAGE_SIZE * 2) && !(flags & KM_NODEBUG))) {
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG(SD_CONSOLE | SD_WARNING,
|
2010-07-26 22:47:55 +00:00
|
|
|
"large kmem_alloc(%llu, 0x%x) at %s:%d (%lld/%llu)\n",
|
2010-06-16 22:57:04 +00:00
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-04 23:54:12 +00:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2012-01-21 00:39:12 +00:00
|
|
|
dump_stack();
|
2010-05-19 23:53:13 +00:00
|
|
|
}
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
/* Use the correct allocator */
|
|
|
|
if (node_alloc) {
|
|
|
|
ASSERT(!(flags & __GFP_ZERO));
|
2009-11-12 23:11:24 +00:00
|
|
|
ptr = kmalloc_node_nofail(size, flags, node);
|
2008-11-03 21:06:04 +00:00
|
|
|
} else if (flags & __GFP_ZERO) {
|
2009-11-12 23:11:24 +00:00
|
|
|
ptr = kzalloc_nofail(size, flags & (~__GFP_ZERO));
|
2008-11-03 21:06:04 +00:00
|
|
|
} else {
|
2009-11-12 23:11:24 +00:00
|
|
|
ptr = kmalloc_nofail(size, flags);
|
2008-11-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
if (unlikely(ptr == NULL)) {
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-06-16 22:57:04 +00:00
|
|
|
"kmem_alloc(%llu, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-04 23:54:12 +00:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-03 21:06:04 +00:00
|
|
|
} else {
|
2009-12-04 23:54:12 +00:00
|
|
|
kmem_alloc_used_add(size);
|
|
|
|
if (unlikely(kmem_alloc_used_read() > kmem_alloc_max))
|
|
|
|
kmem_alloc_max = kmem_alloc_used_read();
|
2008-11-03 21:06:04 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_INFO,
|
2010-06-16 22:57:04 +00:00
|
|
|
"kmem_alloc(%llu, 0x%x) at %s:%d = %p (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line, ptr,
|
2010-07-26 22:47:55 +00:00
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-11-03 21:06:04 +00:00
|
|
|
}
|
2010-07-26 22:47:55 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(ptr);
|
2008-11-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(kmem_alloc_debug);
|
|
|
|
|
|
|
|
void
|
2012-06-25 17:22:21 +00:00
|
|
|
kmem_free_debug(const void *ptr, size_t size)
|
2008-11-03 21:06:04 +00:00
|
|
|
{
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
ASSERTF(ptr || size > 0, "ptr: %p, size: %llu", ptr,
|
|
|
|
(unsigned long long) size);
|
|
|
|
|
2009-12-04 23:54:12 +00:00
|
|
|
kmem_alloc_used_sub(size);
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "kmem_free(%p, %llu) (%lld/%llu)\n", ptr,
|
2009-12-04 23:54:12 +00:00
|
|
|
(unsigned long long) size, kmem_alloc_used_read(),
|
2008-11-03 21:06:04 +00:00
|
|
|
kmem_alloc_max);
|
|
|
|
kfree(ptr);
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-11-03 21:06:04 +00: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 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
ASSERT(flags & KM_SLEEP);
|
|
|
|
|
2010-07-26 22:47:55 +00: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 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-06-16 22:57:04 +00:00
|
|
|
"vmem_alloc(%llu, 0x%x) at %s:%d failed (%lld/%llu)\n",
|
|
|
|
(unsigned long long) size, flags, func, line,
|
2009-12-04 23:54:12 +00:00
|
|
|
vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-03 21:06:04 +00:00
|
|
|
} else {
|
2009-12-04 23:54:12 +00:00
|
|
|
vmem_alloc_used_add(size);
|
|
|
|
if (unlikely(vmem_alloc_used_read() > vmem_alloc_max))
|
|
|
|
vmem_alloc_max = vmem_alloc_used_read();
|
2008-11-03 21:06:04 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "vmem_alloc(%llu, 0x%x) = %p "
|
2008-11-03 21:06:04 +00:00
|
|
|
"(%lld/%llu)\n", (unsigned long long) size, flags, ptr,
|
2009-12-04 23:54:12 +00:00
|
|
|
vmem_alloc_used_read(), vmem_alloc_max);
|
2008-11-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(ptr);
|
2008-11-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vmem_alloc_debug);
|
|
|
|
|
|
|
|
void
|
2012-06-25 17:22:21 +00:00
|
|
|
vmem_free_debug(const void *ptr, size_t size)
|
2008-11-03 21:06:04 +00:00
|
|
|
{
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
ASSERTF(ptr || size > 0, "ptr: %p, size: %llu", ptr,
|
|
|
|
(unsigned long long) size);
|
|
|
|
|
2009-12-04 23:54:12 +00:00
|
|
|
vmem_alloc_used_sub(size);
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_INFO, "vmem_free(%p, %llu) (%lld/%llu)\n", ptr,
|
2009-12-04 23:54:12 +00:00
|
|
|
(unsigned long long) size, vmem_alloc_used_read(),
|
2008-11-03 21:06:04 +00:00
|
|
|
vmem_alloc_max);
|
|
|
|
vfree(ptr);
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-11-03 21:06:04 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(vmem_free_debug);
|
|
|
|
|
|
|
|
# endif /* DEBUG_KMEM_TRACKING */
|
|
|
|
#endif /* DEBUG_KMEM */
|
|
|
|
|
2010-07-26 22:47:55 +00:00
|
|
|
/*
|
|
|
|
* Slab allocation interfaces
|
|
|
|
*
|
|
|
|
* While the Linux slab implementation was inspired by the Solaris
|
2011-10-11 17:11:26 +00:00
|
|
|
* implementation I cannot use it to emulate the Solaris APIs. I
|
2010-07-26 22:47:55 +00: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 17:11:26 +00:00
|
|
|
* virtual address space removes the need for contiguous pages
|
2010-07-26 22:47:55 +00: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 17:11:26 +00:00
|
|
|
* the slab reference count. This guarantees the when freeing
|
2010-07-26 22:47:55 +00: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 17:11:26 +00:00
|
|
|
* particular core. This can be advantageous if you know the slab
|
2010-07-26 22:47:55 +00: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 */
|
|
|
|
|
|
|
|
static int spl_cache_flush(spl_kmem_cache_t *skc,
|
|
|
|
spl_kmem_magazine_t *skm, int flush);
|
|
|
|
|
2011-06-16 22:39:08 +00:00
|
|
|
SPL_SHRINKER_CALLBACK_FWD_DECLARE(spl_kmem_cache_generic_shrinker);
|
2011-03-23 22:45:55 +00:00
|
|
|
SPL_SHRINKER_DECLARE(spl_kmem_cache_shrinker,
|
|
|
|
spl_kmem_cache_generic_shrinker, KMC_DEFAULT_SEEKS);
|
2010-07-26 22:47:55 +00:00
|
|
|
|
2008-07-01 03:28:54 +00:00
|
|
|
static void *
|
|
|
|
kv_alloc(spl_kmem_cache_t *skc, int size, int flags)
|
2008-06-28 05:04:46 +00:00
|
|
|
{
|
2008-07-01 03:28:54 +00:00
|
|
|
void *ptr;
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2009-11-13 19:12:43 +00:00
|
|
|
ASSERT(ISP2(size));
|
|
|
|
|
2012-08-18 18:06:21 +00:00
|
|
|
if (skc->skc_flags & KMC_KMEM)
|
2009-11-13 19:12:43 +00:00
|
|
|
ptr = (void *)__get_free_pages(flags, get_order(size));
|
2012-08-18 18:06:21 +00:00
|
|
|
else
|
2012-08-18 18:05:53 +00:00
|
|
|
ptr = __vmalloc(size, flags | __GFP_HIGHMEM, PAGE_KERNEL);
|
|
|
|
|
2009-11-13 19:12:43 +00:00
|
|
|
/* Resulting allocated memory will be page aligned */
|
|
|
|
ASSERT(IS_P2ALIGNED(ptr, PAGE_SIZE));
|
2008-06-28 05:04:46 +00:00
|
|
|
|
2008-07-01 03:28:54 +00:00
|
|
|
return ptr;
|
|
|
|
}
|
2008-06-28 05:04:46 +00:00
|
|
|
|
2008-07-01 03:28:54 +00:00
|
|
|
static void
|
|
|
|
kv_free(spl_kmem_cache_t *skc, void *ptr, int size)
|
|
|
|
{
|
2009-11-13 19:12:43 +00:00
|
|
|
ASSERT(IS_P2ALIGNED(ptr, PAGE_SIZE));
|
|
|
|
ASSERT(ISP2(size));
|
|
|
|
|
2012-05-01 22:49:07 +00: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 19:12:43 +00: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)
|
|
|
|
{
|
|
|
|
return 1UL << (highbit(spl_obj_size(skc)) + 1);
|
2008-06-28 05:04:46 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* It's important that we pack the spl_kmem_obj_t structure and the
|
2009-01-26 17:02:04 +00: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 17:11:26 +00:00
|
|
|
* it gets increasingly expensive since it requires contiguous pages.
|
2009-01-26 17:02:04 +00:00
|
|
|
* For this reason we shift to vmem_alloc() for slabs of large objects
|
2011-10-11 17:11:26 +00:00
|
|
|
* which removes the need for contiguous pages. We do not use
|
2009-01-26 17:02:04 +00: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 17:11:26 +00:00
|
|
|
* global lock when acquiring an available virtual address range which
|
2009-01-26 17:02:04 +00: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 05:04:46 +00:00
|
|
|
static spl_kmem_slab_t *
|
2008-07-01 03:28:54 +00:00
|
|
|
spl_slab_alloc(spl_kmem_cache_t *skc, int flags)
|
2008-06-28 05:04:46 +00:00
|
|
|
{
|
|
|
|
spl_kmem_slab_t *sks;
|
2008-07-01 03:28:54 +00:00
|
|
|
spl_kmem_obj_t *sko, *n;
|
|
|
|
void *base, *obj;
|
2009-11-13 19:12:43 +00:00
|
|
|
uint32_t obj_size, offslab_size = 0;
|
|
|
|
int i, rc = 0;
|
2009-01-26 17:02:04 +00:00
|
|
|
|
2008-07-01 03:28:54 +00:00
|
|
|
base = kv_alloc(skc, skc->skc_slab_size, flags);
|
|
|
|
if (base == NULL)
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(NULL);
|
2008-06-28 05:04:46 +00:00
|
|
|
|
2008-07-01 03:28:54 +00: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 19:12:43 +00:00
|
|
|
obj_size = spl_obj_size(skc);
|
2009-01-26 17:02:04 +00:00
|
|
|
|
2011-10-11 17:03:29 +00:00
|
|
|
if (skc->skc_flags & KMC_OFFSLAB)
|
2009-11-13 19:12:43 +00:00
|
|
|
offslab_size = spl_offslab_size(skc);
|
2008-06-28 05:04:46 +00:00
|
|
|
|
|
|
|
for (i = 0; i < sks->sks_objs; i++) {
|
2008-07-01 03:28:54 +00:00
|
|
|
if (skc->skc_flags & KMC_OFFSLAB) {
|
2009-11-13 19:12:43 +00:00
|
|
|
obj = kv_alloc(skc, offslab_size, flags);
|
2008-07-01 03:28:54 +00:00
|
|
|
if (!obj)
|
2010-07-20 18:55:37 +00:00
|
|
|
SGOTO(out, rc = -ENOMEM);
|
2008-07-01 03:28:54 +00:00
|
|
|
} else {
|
2009-11-13 19:12:43 +00:00
|
|
|
obj = base + spl_sks_size(skc) + (i * obj_size);
|
2008-07-01 03:28:54 +00:00
|
|
|
}
|
|
|
|
|
2009-11-13 19:12:43 +00:00
|
|
|
ASSERT(IS_P2ALIGNED(obj, skc->skc_obj_align));
|
|
|
|
sko = spl_sko_from_obj(skc, obj);
|
2008-06-28 05:04:46 +00: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-13 23:41:06 +00:00
|
|
|
out:
|
2008-07-01 03:28:54 +00:00
|
|
|
if (rc) {
|
|
|
|
if (skc->skc_flags & KMC_OFFSLAB)
|
2009-01-26 17:02:04 +00:00
|
|
|
list_for_each_entry_safe(sko, n, &sks->sks_free_list,
|
|
|
|
sko_list)
|
2009-11-13 19:12:43 +00:00
|
|
|
kv_free(skc, sko->sko_addr, offslab_size);
|
2008-06-28 05:04:46 +00:00
|
|
|
|
2008-07-01 03:28:54 +00:00
|
|
|
kv_free(skc, base, skc->skc_slab_size);
|
|
|
|
sks = NULL;
|
2008-06-28 05:04:46 +00:00
|
|
|
}
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(sks);
|
2008-06-28 05:04:46 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00: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 05:04:46 +00:00
|
|
|
*/
|
2008-02-26 20:36:04 +00:00
|
|
|
static void
|
2009-01-31 04:54:49 +00:00
|
|
|
spl_slab_free(spl_kmem_slab_t *sks,
|
|
|
|
struct list_head *sks_list, struct list_head *sko_list)
|
|
|
|
{
|
2008-06-13 23:41:06 +00:00
|
|
|
spl_kmem_cache_t *skc;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-02 17:28:49 +00:00
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
ASSERT(sks->sks_magic == SKS_MAGIC);
|
2008-06-25 20:57:45 +00:00
|
|
|
ASSERT(sks->sks_ref == 0);
|
2008-05-06 20:38:28 +00:00
|
|
|
|
2008-06-28 05:04:46 +00:00
|
|
|
skc = sks->sks_cache;
|
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2008-06-24 17:18:15 +00:00
|
|
|
ASSERT(spin_is_locked(&skc->skc_lock));
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2009-02-13 18:28:55 +00: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 05:04:46 +00:00
|
|
|
skc->skc_obj_total -= sks->sks_objs;
|
|
|
|
skc->skc_slab_total--;
|
|
|
|
list_del(&sks->sks_list);
|
2009-01-31 04:54:49 +00:00
|
|
|
list_add(&sks->sks_list, sks_list);
|
2009-02-13 18:28:55 +00:00
|
|
|
list_splice_init(&sks->sks_free_list, sko_list);
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-06-13 23:41:06 +00:00
|
|
|
}
|
2008-05-06 20:38:28 +00:00
|
|
|
|
2009-01-31 04:54:49 +00: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-12 21:32:10 +00: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 04:54:49 +00:00
|
|
|
*/
|
|
|
|
static void
|
2009-02-12 21:32:10 +00:00
|
|
|
spl_slab_reclaim(spl_kmem_cache_t *skc, int count, int flag)
|
2008-06-13 23:41:06 +00:00
|
|
|
{
|
|
|
|
spl_kmem_slab_t *sks, *m;
|
2009-01-31 04:54:49 +00:00
|
|
|
spl_kmem_obj_t *sko, *n;
|
|
|
|
LIST_HEAD(sks_list);
|
|
|
|
LIST_HEAD(sko_list);
|
2009-11-13 19:12:43 +00:00
|
|
|
uint32_t size = 0;
|
|
|
|
int i = 0;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-13 23:41:06 +00:00
|
|
|
|
|
|
|
/*
|
2009-01-31 04:54:49 +00: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 18:28:55 +00: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-13 23:41:06 +00:00
|
|
|
*/
|
2009-01-31 04:54:49 +00:00
|
|
|
spin_lock(&skc->skc_lock);
|
2009-02-13 18:28:55 +00: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 17:11:26 +00:00
|
|
|
* reclaim 'count' if a non-zero threshold is given.
|
2009-02-13 18:28:55 +00:00
|
|
|
*/
|
2012-04-27 22:10:02 +00:00
|
|
|
if ((sks->sks_ref > 0) || (count && i >= count))
|
2009-02-12 21:32:10 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
if (time_after(jiffies,sks->sks_age+skc->skc_delay*HZ)||flag) {
|
2009-01-31 04:54:49 +00:00
|
|
|
spl_slab_free(sks, &sks_list, &sko_list);
|
2009-02-12 21:32:10 +00:00
|
|
|
i++;
|
|
|
|
}
|
2009-01-31 04:54:49 +00:00
|
|
|
}
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
|
|
|
/*
|
2009-02-13 18:28:55 +00: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 04:54:49 +00:00
|
|
|
*/
|
2009-02-13 18:28:55 +00:00
|
|
|
if (skc->skc_flags & KMC_OFFSLAB)
|
2009-11-13 19:12:43 +00:00
|
|
|
size = spl_offslab_size(skc);
|
2009-01-31 04:54:49 +00:00
|
|
|
|
2009-02-13 18:28:55 +00: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 04:54:49 +00:00
|
|
|
kv_free(skc, sko->sko_addr, size);
|
2009-02-13 18:28:55 +00:00
|
|
|
|
|
|
|
cond_resched();
|
2008-06-13 23:41:06 +00:00
|
|
|
}
|
|
|
|
|
2009-02-12 21:32:10 +00:00
|
|
|
list_for_each_entry_safe(sks, m, &sks_list, sks_list) {
|
2009-02-13 18:28:55 +00:00
|
|
|
ASSERT(sks->sks_magic == SKS_MAGIC);
|
2009-01-31 04:54:49 +00:00
|
|
|
kv_free(skc, sks, skc->skc_slab_size);
|
2009-02-12 21:32:10 +00:00
|
|
|
cond_resched();
|
|
|
|
}
|
2009-01-31 04:54:49 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-02-26 20:36:04 +00:00
|
|
|
}
|
|
|
|
|
2012-10-30 17:45:50 +00: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-07 23:59:50 +00:00
|
|
|
/*
|
2012-10-30 17:45:50 +00: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-07 23:59:50 +00: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 17:45:50 +00: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-07 23:59:50 +00:00
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
2012-10-30 17:45:50 +00: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-07 23:59:50 +00:00
|
|
|
*obj = ske->ske_obj;
|
|
|
|
|
|
|
|
SRETURN(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2012-10-30 17:45:50 +00: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-07 23:59:50 +00:00
|
|
|
*/
|
|
|
|
static int
|
|
|
|
spl_emergency_free(spl_kmem_cache_t *skc, void *obj)
|
|
|
|
{
|
2012-10-30 17:45:50 +00: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-07 23:59:50 +00:00
|
|
|
SENTRY;
|
|
|
|
|
|
|
|
spin_lock(&skc->skc_lock);
|
2012-10-30 17:45:50 +00: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-07 23:59:50 +00:00
|
|
|
}
|
|
|
|
spin_unlock(&skc->skc_lock);
|
|
|
|
|
2012-10-30 17:45:50 +00: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-07 23:59:50 +00:00
|
|
|
SRETURN(-ENOENT);
|
|
|
|
|
|
|
|
if (skc->skc_dtor)
|
|
|
|
skc->skc_dtor(ske->ske_obj, skc->skc_private);
|
|
|
|
|
|
|
|
kfree(ske->ske_obj);
|
|
|
|
kfree(ske);
|
|
|
|
|
|
|
|
SRETURN(0);
|
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* Called regularly on all caches to age objects out of the magazines
|
|
|
|
* which have not been access in skc->skc_delay seconds. This prevents
|
|
|
|
* idle magazines from holding memory which might be better used by
|
|
|
|
* other caches or parts of the system. The delay is present to
|
|
|
|
* prevent thrashing the magazine.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
spl_magazine_age(void *data)
|
2008-02-26 20:36:04 +00:00
|
|
|
{
|
2009-02-17 23:52:18 +00:00
|
|
|
spl_kmem_magazine_t *skm =
|
|
|
|
spl_get_work_data(data, spl_kmem_magazine_t, skm_work.work);
|
|
|
|
spl_kmem_cache_t *skc = skm->skm_cache;
|
|
|
|
|
|
|
|
ASSERT(skm->skm_magic == SKM_MAGIC);
|
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2012-08-23 21:00:58 +00:00
|
|
|
ASSERT(skc->skc_mag[skm->skm_cpu] == skm);
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
if (skm->skm_avail > 0 &&
|
|
|
|
time_after(jiffies, skm->skm_age + skc->skc_delay * HZ))
|
|
|
|
(void)spl_cache_flush(skc, skm, skm->skm_refill);
|
2009-02-17 23:52:18 +00:00
|
|
|
|
|
|
|
if (!test_bit(KMC_BIT_DESTROY, &skc->skc_flags))
|
2012-08-23 21:00:58 +00:00
|
|
|
schedule_delayed_work_on(skm->skm_cpu, &skm->skm_work,
|
2009-02-17 23:52:18 +00:00
|
|
|
skc->skc_delay / 3 * HZ);
|
2009-01-31 04:54:49 +00:00
|
|
|
}
|
2008-05-15 17:10:30 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* Called regularly to keep a downward pressure on the size of idle
|
|
|
|
* magazines and to release free slabs from the cache. This function
|
2011-10-11 17:11:26 +00:00
|
|
|
* never calls the registered reclaim function, that only occurs
|
2009-01-31 04:54:49 +00:00
|
|
|
* under memory pressure or with a direct call to spl_kmem_reap().
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
spl_cache_age(void *data)
|
|
|
|
{
|
2009-02-17 23:52:18 +00:00
|
|
|
spl_kmem_cache_t *skc =
|
2009-01-31 04:54:49 +00:00
|
|
|
spl_get_work_data(data, spl_kmem_cache_t, skc_work.work);
|
|
|
|
|
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2009-02-12 21:32:10 +00:00
|
|
|
spl_slab_reclaim(skc, skc->skc_reap, 0);
|
2009-01-31 04:54:49 +00:00
|
|
|
|
|
|
|
if (!test_bit(KMC_BIT_DESTROY, &skc->skc_flags))
|
2009-02-12 21:32:10 +00:00
|
|
|
schedule_delayed_work(&skc->skc_work, skc->skc_delay / 3 * HZ);
|
2008-06-13 23:41:06 +00:00
|
|
|
}
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
2009-11-13 19:12:43 +00:00
|
|
|
* Size a slab based on the size of each aligned object plus spl_kmem_obj_t.
|
2009-01-31 04:54:49 +00:00
|
|
|
* When on-slab we want to target SPL_KMEM_CACHE_OBJ_PER_SLAB. However,
|
|
|
|
* 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
|
|
|
|
* very large objects we may use as few as SPL_KMEM_CACHE_OBJ_PER_SLAB_MIN,
|
|
|
|
* lower than this and we will fail.
|
|
|
|
*/
|
2009-01-26 17:02:04 +00:00
|
|
|
static int
|
|
|
|
spl_slab_size(spl_kmem_cache_t *skc, uint32_t *objs, uint32_t *size)
|
|
|
|
{
|
2009-11-13 19:12:43 +00:00
|
|
|
uint32_t sks_size, obj_size, max_size;
|
2009-01-26 17:02:04 +00:00
|
|
|
|
|
|
|
if (skc->skc_flags & KMC_OFFSLAB) {
|
2009-01-31 04:54:49 +00:00
|
|
|
*objs = SPL_KMEM_CACHE_OBJ_PER_SLAB;
|
2009-01-26 17:02:04 +00:00
|
|
|
*size = sizeof(spl_kmem_slab_t);
|
|
|
|
} else {
|
2009-11-13 19:12:43 +00:00
|
|
|
sks_size = spl_sks_size(skc);
|
|
|
|
obj_size = spl_obj_size(skc);
|
2009-01-31 04:54:49 +00:00
|
|
|
|
|
|
|
if (skc->skc_flags & KMC_KMEM)
|
2010-03-18 20:39:51 +00:00
|
|
|
max_size = ((uint32_t)1 << (MAX_ORDER-3)) * PAGE_SIZE;
|
2009-01-31 04:54:49 +00:00
|
|
|
else
|
|
|
|
max_size = (32 * 1024 * 1024);
|
2009-01-26 17:02:04 +00:00
|
|
|
|
2009-11-13 19:12:43 +00:00
|
|
|
/* Power of two sized slab */
|
|
|
|
for (*size = PAGE_SIZE; *size <= max_size; *size *= 2) {
|
2009-01-31 04:54:49 +00:00
|
|
|
*objs = (*size - sks_size) / obj_size;
|
|
|
|
if (*objs >= SPL_KMEM_CACHE_OBJ_PER_SLAB)
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(0);
|
2009-01-31 04:54:49 +00:00
|
|
|
}
|
2009-01-26 17:02:04 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
2009-11-13 19:12:43 +00:00
|
|
|
* Unable to satisfy target objects per slab, fall back to
|
2009-01-31 04:54:49 +00: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;
|
|
|
|
if (*objs >= SPL_KMEM_CACHE_OBJ_PER_SLAB_MIN)
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(0);
|
2009-01-26 17:02:04 +00:00
|
|
|
}
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(-ENOSPC);
|
2009-01-26 17:02:04 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00: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-25 20:57:45 +00:00
|
|
|
static int
|
|
|
|
spl_magazine_size(spl_kmem_cache_t *skc)
|
|
|
|
{
|
2009-11-13 19:12:43 +00:00
|
|
|
uint32_t obj_size = spl_obj_size(skc);
|
|
|
|
int size;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/* Per-magazine sizes below assume a 4Kib page size */
|
2009-11-13 19:12:43 +00:00
|
|
|
if (obj_size > (PAGE_SIZE * 256))
|
2009-01-31 04:54:49 +00:00
|
|
|
size = 4; /* Minimum 4Mib per-magazine */
|
2009-11-13 19:12:43 +00:00
|
|
|
else if (obj_size > (PAGE_SIZE * 32))
|
2009-01-31 04:54:49 +00:00
|
|
|
size = 16; /* Minimum 2Mib per-magazine */
|
2009-11-13 19:12:43 +00:00
|
|
|
else if (obj_size > (PAGE_SIZE))
|
2009-01-31 04:54:49 +00:00
|
|
|
size = 64; /* Minimum 256Kib per-magazine */
|
2009-11-13 19:12:43 +00:00
|
|
|
else if (obj_size > (PAGE_SIZE / 4))
|
2009-01-31 04:54:49 +00:00
|
|
|
size = 128; /* Minimum 128Kib per-magazine */
|
2008-06-25 20:57:45 +00:00
|
|
|
else
|
2009-01-31 04:54:49 +00:00
|
|
|
size = 256;
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(size);
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
2011-10-11 17:11:26 +00:00
|
|
|
* Allocate a per-cpu magazine to associate with a specific core.
|
2009-01-31 04:54:49 +00:00
|
|
|
*/
|
2008-06-25 20:57:45 +00:00
|
|
|
static spl_kmem_magazine_t *
|
2012-08-23 21:00:58 +00:00
|
|
|
spl_magazine_alloc(spl_kmem_cache_t *skc, int cpu)
|
2008-06-25 20:57:45 +00:00
|
|
|
{
|
|
|
|
spl_kmem_magazine_t *skm;
|
|
|
|
int size = sizeof(spl_kmem_magazine_t) +
|
|
|
|
sizeof(void *) * skc->skc_mag_size;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2012-08-23 21:00:58 +00:00
|
|
|
skm = kmem_alloc_node(size, KM_SLEEP, cpu_to_node(cpu));
|
2008-06-25 20:57:45 +00: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-17 23:52:18 +00:00
|
|
|
skm->skm_cache = skc;
|
|
|
|
spl_init_delayed_work(&skm->skm_work, spl_magazine_age, skm);
|
2009-01-31 04:54:49 +00:00
|
|
|
skm->skm_age = jiffies;
|
2012-08-23 21:00:58 +00:00
|
|
|
skm->skm_cpu = cpu;
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(skm);
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
2011-10-11 17:11:26 +00:00
|
|
|
* Free a per-cpu magazine associated with a specific core.
|
2009-01-31 04:54:49 +00:00
|
|
|
*/
|
2008-06-25 20:57:45 +00:00
|
|
|
static void
|
|
|
|
spl_magazine_free(spl_kmem_magazine_t *skm)
|
|
|
|
{
|
2008-11-03 21:06:04 +00:00
|
|
|
int size = sizeof(spl_kmem_magazine_t) +
|
|
|
|
sizeof(void *) * skm->skm_size;
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-25 20:57:45 +00:00
|
|
|
ASSERT(skm->skm_magic == SKM_MAGIC);
|
|
|
|
ASSERT(skm->skm_avail == 0);
|
2008-11-03 21:06:04 +00:00
|
|
|
|
|
|
|
kmem_free(skm, size);
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* Create all pre-cpu magazines of reasonable sizes.
|
|
|
|
*/
|
2008-06-25 20:57:45 +00:00
|
|
|
static int
|
|
|
|
spl_magazine_create(spl_kmem_cache_t *skc)
|
|
|
|
{
|
2009-02-12 21:32:10 +00:00
|
|
|
int i;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-25 20:57:45 +00:00
|
|
|
|
|
|
|
skc->skc_mag_size = spl_magazine_size(skc);
|
2009-01-31 04:54:49 +00:00
|
|
|
skc->skc_mag_refill = (skc->skc_mag_size + 1) / 2;
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2009-02-12 21:32:10 +00:00
|
|
|
for_each_online_cpu(i) {
|
2012-08-23 21:00:58 +00:00
|
|
|
skc->skc_mag[i] = spl_magazine_alloc(skc, i);
|
2009-02-12 21:32:10 +00:00
|
|
|
if (!skc->skc_mag[i]) {
|
|
|
|
for (i--; i >= 0; i--)
|
|
|
|
spl_magazine_free(skc->skc_mag[i]);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(-ENOMEM);
|
2009-02-12 21:32:10 +00:00
|
|
|
}
|
|
|
|
}
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2009-02-17 23:52:18 +00:00
|
|
|
/* Only after everything is allocated schedule magazine work */
|
|
|
|
for_each_online_cpu(i)
|
|
|
|
schedule_delayed_work_on(i, &skc->skc_mag[i]->skm_work,
|
|
|
|
skc->skc_delay / 3 * HZ);
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(0);
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* Destroy all pre-cpu magazines.
|
|
|
|
*/
|
2008-06-25 20:57:45 +00:00
|
|
|
static void
|
|
|
|
spl_magazine_destroy(spl_kmem_cache_t *skc)
|
|
|
|
{
|
2009-02-12 21:32:10 +00:00
|
|
|
spl_kmem_magazine_t *skm;
|
|
|
|
int i;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2009-02-12 21:32:10 +00:00
|
|
|
|
|
|
|
for_each_online_cpu(i) {
|
|
|
|
skm = skc->skc_mag[i];
|
|
|
|
(void)spl_cache_flush(skc, skm, skm->skm_avail);
|
|
|
|
spl_magazine_free(skm);
|
|
|
|
}
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00: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_NOMAGAZINE Disable magazine (unsupported)
|
|
|
|
* KMC_NOHASH Disable hashing (unsupported)
|
|
|
|
* KMC_QCACHE Disable qcache (unsupported)
|
|
|
|
* KMC_KMEM Force kmem backed cache
|
|
|
|
* KMC_VMEM Force vmem backed cache
|
|
|
|
* KMC_OFFSLAB Locate objects off the slab
|
|
|
|
*/
|
2008-06-13 23:41:06 +00: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 19:01:08 +00:00
|
|
|
int rc;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-04-21 17:29:47 +00:00
|
|
|
|
2008-07-01 03:28:54 +00: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 17:02:04 +00:00
|
|
|
ASSERT(vmp == NULL);
|
2008-07-01 03:28:54 +00:00
|
|
|
|
2012-12-10 19:01:08 +00:00
|
|
|
might_sleep();
|
2008-04-03 16:33:31 +00:00
|
|
|
|
2012-12-10 19:01:08 +00:00
|
|
|
/*
|
|
|
|
* Allocate memory for a new cache an initialize it. Unfortunately,
|
2010-05-19 23:53:13 +00: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 19:01:08 +00:00
|
|
|
* explicitly pass KM_NODEBUG to suppress the kmem warning
|
|
|
|
*/
|
|
|
|
skc = kmem_zalloc(sizeof(*skc), KM_SLEEP| KM_NODEBUG);
|
2008-06-26 19:49:42 +00:00
|
|
|
if (skc == NULL)
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(NULL);
|
2008-04-15 20:53:36 +00:00
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
skc->skc_magic = SKC_MAGIC;
|
|
|
|
skc->skc_name_size = strlen(name) + 1;
|
2012-12-10 19:01:08 +00:00
|
|
|
skc->skc_name = (char *)kmem_alloc(skc->skc_name_size, KM_SLEEP);
|
2008-06-13 23:41:06 +00:00
|
|
|
if (skc->skc_name == NULL) {
|
|
|
|
kmem_free(skc, sizeof(*skc));
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(NULL);
|
2008-06-13 23:41:06 +00:00
|
|
|
}
|
|
|
|
strncpy(skc->skc_name, name, skc->skc_name_size);
|
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
skc->skc_ctor = ctor;
|
|
|
|
skc->skc_dtor = dtor;
|
|
|
|
skc->skc_reclaim = reclaim;
|
2008-06-13 23:41:06 +00:00
|
|
|
skc->skc_private = priv;
|
|
|
|
skc->skc_vmp = vmp;
|
|
|
|
skc->skc_flags = flags;
|
|
|
|
skc->skc_obj_size = size;
|
2009-01-26 17:02:04 +00:00
|
|
|
skc->skc_obj_align = SPL_KMEM_CACHE_ALIGN;
|
2008-06-13 23:41:06 +00:00
|
|
|
skc->skc_delay = SPL_KMEM_CACHE_DELAY;
|
2009-02-12 21:32:10 +00:00
|
|
|
skc->skc_reap = SPL_KMEM_CACHE_REAP;
|
2009-01-31 04:54:49 +00:00
|
|
|
atomic_set(&skc->skc_ref, 0);
|
2008-06-13 23:41:06 +00:00
|
|
|
|
|
|
|
INIT_LIST_HEAD(&skc->skc_list);
|
|
|
|
INIT_LIST_HEAD(&skc->skc_complete_list);
|
|
|
|
INIT_LIST_HEAD(&skc->skc_partial_list);
|
2012-10-30 17:45:50 +00:00
|
|
|
skc->skc_emergency_tree = RB_ROOT;
|
2008-06-24 17:18:15 +00: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-07 23:59:50 +00:00
|
|
|
init_waitqueue_head(&skc->skc_waitq);
|
2008-06-26 19:49:42 +00:00
|
|
|
skc->skc_slab_fail = 0;
|
|
|
|
skc->skc_slab_create = 0;
|
|
|
|
skc->skc_slab_destroy = 0;
|
2008-06-13 23:41:06 +00: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-29 23:51:59 +00: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-07 23:59:50 +00:00
|
|
|
skc->skc_obj_emergency = 0;
|
|
|
|
skc->skc_obj_emergency_max = 0;
|
2008-07-01 03:28:54 +00:00
|
|
|
|
2009-01-26 17:02:04 +00:00
|
|
|
if (align) {
|
2009-11-13 19:12:43 +00:00
|
|
|
VERIFY(ISP2(align));
|
|
|
|
VERIFY3U(align, >=, SPL_KMEM_CACHE_ALIGN); /* Min alignment */
|
|
|
|
VERIFY3U(align, <=, PAGE_SIZE); /* Max alignment */
|
2009-01-26 17:02:04 +00:00
|
|
|
skc->skc_obj_align = align;
|
|
|
|
}
|
|
|
|
|
2008-07-01 03:28:54 +00:00
|
|
|
/* If none passed select a cache type based on object size */
|
|
|
|
if (!(skc->skc_flags & (KMC_KMEM | KMC_VMEM))) {
|
2009-11-13 19:12:43 +00:00
|
|
|
if (spl_obj_size(skc) < (PAGE_SIZE / 8))
|
2008-07-01 03:28:54 +00:00
|
|
|
skc->skc_flags |= KMC_KMEM;
|
2009-11-13 19:12:43 +00:00
|
|
|
else
|
2008-07-01 03:28:54 +00:00
|
|
|
skc->skc_flags |= KMC_VMEM;
|
|
|
|
}
|
|
|
|
|
2009-01-26 17:02:04 +00:00
|
|
|
rc = spl_slab_size(skc, &skc->skc_slab_objs, &skc->skc_slab_size);
|
|
|
|
if (rc)
|
2010-07-20 18:55:37 +00:00
|
|
|
SGOTO(out, rc);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
|
|
|
rc = spl_magazine_create(skc);
|
2009-01-26 17:02:04 +00:00
|
|
|
if (rc)
|
2010-07-20 18:55:37 +00:00
|
|
|
SGOTO(out, rc);
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
spl_init_delayed_work(&skc->skc_work, spl_cache_age, skc);
|
2009-02-12 21:32:10 +00:00
|
|
|
schedule_delayed_work(&skc->skc_work, skc->skc_delay / 3 * HZ);
|
2009-01-31 04:54:49 +00:00
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
down_write(&spl_kmem_cache_sem);
|
2008-06-26 19:49:42 +00:00
|
|
|
list_add_tail(&skc->skc_list, &spl_kmem_cache_list);
|
2008-06-13 23:41:06 +00:00
|
|
|
up_write(&spl_kmem_cache_sem);
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(skc);
|
2009-01-26 17:02:04 +00:00
|
|
|
out:
|
|
|
|
kmem_free(skc->skc_name, skc->skc_name_size);
|
|
|
|
kmem_free(skc, sizeof(*skc));
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(NULL);
|
2008-02-26 20:36:04 +00:00
|
|
|
}
|
2008-06-13 23:41:06 +00:00
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_create);
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2010-08-27 20:28:10 +00:00
|
|
|
/*
|
|
|
|
* Register a move callback to for cache defragmentation.
|
|
|
|
* XXX: Unimplemented but harmless to stub out for now.
|
|
|
|
*/
|
|
|
|
void
|
2012-08-01 06:00:40 +00:00
|
|
|
spl_kmem_cache_set_move(spl_kmem_cache_t *skc,
|
2010-08-27 20:28:10 +00:00
|
|
|
kmem_cbrc_t (move)(void *, void *, size_t, void *))
|
|
|
|
{
|
|
|
|
ASSERT(move != NULL);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_set_move);
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
2011-10-11 17:11:26 +00:00
|
|
|
* Destroy a cache and all objects associated with the cache.
|
2009-01-31 04:54:49 +00:00
|
|
|
*/
|
2008-06-13 23:41:06 +00:00
|
|
|
void
|
|
|
|
spl_kmem_cache_destroy(spl_kmem_cache_t *skc)
|
2008-02-26 20:36:04 +00:00
|
|
|
{
|
2009-01-31 04:54:49 +00:00
|
|
|
DECLARE_WAIT_QUEUE_HEAD(wq);
|
2009-02-17 23:52:18 +00:00
|
|
|
int i;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
|
|
|
|
|
|
|
down_write(&spl_kmem_cache_sem);
|
|
|
|
list_del_init(&skc->skc_list);
|
|
|
|
up_write(&spl_kmem_cache_sem);
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/* Cancel any and wait for any pending delayed work */
|
2011-10-11 16:59:02 +00:00
|
|
|
VERIFY(!test_and_set_bit(KMC_BIT_DESTROY, &skc->skc_flags));
|
|
|
|
cancel_delayed_work_sync(&skc->skc_work);
|
2009-02-17 23:52:18 +00:00
|
|
|
for_each_online_cpu(i)
|
2011-10-11 16:59:02 +00:00
|
|
|
cancel_delayed_work_sync(&skc->skc_mag[i]->skm_work);
|
2009-02-17 23:52:18 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
flush_scheduled_work();
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
spl_magazine_destroy(skc);
|
2009-02-12 21:32:10 +00:00
|
|
|
spl_slab_reclaim(skc, 0, 1);
|
2008-06-24 17:18:15 +00:00
|
|
|
spin_lock(&skc->skc_lock);
|
2008-05-06 20:38:28 +00:00
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
/* Validate there are no objects in use and free all the
|
2008-06-25 20:57:45 +00:00
|
|
|
* spl_kmem_slab_t, spl_kmem_obj_t, and object buffers. */
|
2009-01-31 04:54:49 +00: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-07 23:59:50 +00:00
|
|
|
ASSERT3U(skc->skc_obj_emergency, ==, 0);
|
2008-06-13 23:41:06 +00:00
|
|
|
ASSERT(list_empty(&skc->skc_complete_list));
|
2008-07-01 03:28:54 +00:00
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
kmem_free(skc->skc_name, skc->skc_name_size);
|
2008-06-24 17:18:15 +00:00
|
|
|
spin_unlock(&skc->skc_lock);
|
2008-06-27 21:40:11 +00:00
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
kmem_free(skc, sizeof(*skc));
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-02-26 20:36:04 +00:00
|
|
|
}
|
2008-06-13 23:41:06 +00:00
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_destroy);
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2009-01-31 04:54:49 +00: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-25 20:57:45 +00:00
|
|
|
static void *
|
|
|
|
spl_cache_obj(spl_kmem_cache_t *skc, spl_kmem_slab_t *sks)
|
2008-02-26 20:36:04 +00:00
|
|
|
{
|
2008-06-13 23:41:06 +00:00
|
|
|
spl_kmem_obj_t *sko;
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
|
|
|
ASSERT(sks->sks_magic == SKS_MAGIC);
|
2008-06-25 20:57:45 +00:00
|
|
|
ASSERT(spin_is_locked(&skc->skc_lock));
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2008-07-01 03:28:54 +00:00
|
|
|
sko = list_entry(sks->sks_free_list.next, spl_kmem_obj_t, sko_list);
|
2008-06-25 20:57:45 +00:00
|
|
|
ASSERT(sko->sko_magic == SKO_MAGIC);
|
|
|
|
ASSERT(sko->sko_addr != NULL);
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2008-07-01 03:28:54 +00:00
|
|
|
/* Remove from sks_free_list */
|
2008-06-25 20:57:45 +00:00
|
|
|
list_del_init(&sko->sko_list);
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
sks->sks_age = jiffies;
|
|
|
|
sks->sks_ref++;
|
|
|
|
skc->skc_obj_alloc++;
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2008-06-25 20:57:45 +00: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-13 23:41:06 +00:00
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
/* Track max slab usage statistics */
|
|
|
|
if (sks->sks_ref == 1) {
|
|
|
|
skc->skc_slab_alloc++;
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
if (skc->skc_slab_alloc > skc->skc_slab_max)
|
|
|
|
skc->skc_slab_max = skc->skc_slab_alloc;
|
2008-06-13 23:41:06 +00:00
|
|
|
}
|
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
return sko->sko_addr;
|
|
|
|
}
|
2008-06-04 06:00:46 +00:00
|
|
|
|
2009-01-31 04:54:49 +00: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-07 23:59:50 +00: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-25 20:57:45 +00: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-07 23:59:50 +00:00
|
|
|
static void
|
|
|
|
spl_cache_grow_work(void *data)
|
2008-06-25 20:57:45 +00: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-07 23:59:50 +00:00
|
|
|
spl_kmem_alloc_t *ska =
|
|
|
|
spl_get_work_data(data, spl_kmem_alloc_t, ska_work.work);
|
|
|
|
spl_kmem_cache_t *skc = ska->ska_cache;
|
2008-06-26 19:49:42 +00: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-07 23:59:50 +00: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-29 23:51:59 +00: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-07 23:59:50 +00: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);
|
|
|
|
}
|
|
|
|
|
2012-11-05 21:54:20 +00:00
|
|
|
static int
|
|
|
|
spl_cache_reclaim_wait(void *word)
|
|
|
|
{
|
|
|
|
schedule();
|
|
|
|
return 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-07 23:59:50 +00:00
|
|
|
/*
|
|
|
|
* No available objects on any slabs, create a new slab.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
spl_cache_grow(spl_kmem_cache_t *skc, int flags, void **obj)
|
|
|
|
{
|
2012-10-29 23:51:59 +00:00
|
|
|
int remaining, rc;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2009-01-31 04:54:49 +00: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-07 23:59:50 +00:00
|
|
|
*obj = NULL;
|
2008-06-26 19:49:42 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
2012-11-05 21:54:20 +00: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 04:54:49 +00:00
|
|
|
*/
|
2012-11-05 21:54:20 +00:00
|
|
|
if (test_bit(KMC_BIT_REAPING, &skc->skc_flags)) {
|
|
|
|
rc = wait_on_bit(&skc->skc_flags, KMC_BIT_REAPING,
|
|
|
|
spl_cache_reclaim_wait, TASK_UNINTERRUPTIBLE);
|
|
|
|
SRETURN(rc ? rc : -EAGAIN);
|
|
|
|
}
|
2008-06-13 23:41:06 +00: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-07 23:59:50 +00: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-25 20:57:45 +00: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-07 23:59:50 +00: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-25 20:57:45 +00: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-07 23:59:50 +00:00
|
|
|
atomic_inc(&skc->skc_ref);
|
|
|
|
ska->ska_cache = skc;
|
2012-11-27 00:52:28 +00:00
|
|
|
ska->ska_flags = flags & ~__GFP_FS;
|
Emergency slab objects
This patch is designed to resolve a deadlock which can occur with
__vmalloc() based slabs. The issue is that the Linux kernel does
not honor the flags passed to __vmalloc(). This makes it unsafe
to use in a writeback context. Unfortunately, this is a use case
ZFS depends on for correct operation.
Fixing this issue in the upstream kernel was pursued and patches
are available which resolve the issue.
https://bugs.gentoo.org/show_bug.cgi?id=416685
However, these changes were rejected because upstream felt that
using __vmalloc() in the context of writeback should never be done.
Their solution was for us to rewrite parts of ZFS to accomidate
the Linux VM.
While that is probably the right long term solution, and it is
something we want to pursue, it is not a trivial task and will
likely destabilize the existing code. This work has been planned
for the 0.7.0 release but in the meanwhile we want to improve the
SPL slab implementation to accomidate this expected ZFS usage.
This is accomplished by performing the __vmalloc() asynchronously
in the context of a work queue. This doesn't prevent the posibility
of the worker thread from deadlocking. However, the caller can now
safely block on a wait queue for the slab allocation to complete.
Normally this will occur in a reasonable amount of time and the
caller will be woken up when the new slab is available,. The objects
will then get cached in the per-cpu magazines and everything will
proceed as usual.
However, if the __vmalloc() deadlocks for the reasons described
above, or is just very slow, then the callers on the wait queues
will timeout out. When this rare situation occurs they will attempt
to kmalloc() a single minimally sized object using the GFP_NOIO flags.
This allocation will not deadlock because kmalloc() will honor the
passed flags and the caller will be able to make forward progress.
As long as forward progress can be maintained then even if the
worker thread is deadlocked the critical thread will make progress.
This will eventually allow the deadlocked worker thread to complete
and normal operation will resume.
These emergency allocations will likely be slow since they require
contiguous pages. However, their use should be rare so the impact
is expected to be minimal. If that turns out not to be the case in
practice further optimizations are possible.
One additional concern is if these emergency objects are long lived.
Right now they are simply tracked on a list which must be walked when
an object is freed. Is they accumulate on a system and the list
grows freeing objects will become more expensive. This could be
handled relatively easily by using a hash instead of a list, but that
optimization (if needed) is left for a follow up patch.
Additionally, these emeregency objects could be repacked in to existing
slabs as objects are freed if the kmem_cache_set_move() functionality
was implemented. See issue https://github.com/zfsonlinux/spl/issues/26
for full details. This work would also help reduce ZFS's memory
fragmentation problems.
The /proc/spl/kmem/slab file has had two new columns added at the
end. The 'emerg' column reports the current number of these emergency
objects in use for the cache, and the following 'max' column shows
the historical worst case. These value should give us a good idea
of how often these objects are needed. Based on these values under
real use cases we can tune the default behavior.
Lastly, as a side benefit using a single work queue for the slab
allocations should reduce cpu contention on the global virtual address
space lock. This should manifest itself as reduced cpu usage for
the system.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-08-07 23:59:50 +00:00
|
|
|
spl_init_delayed_work(&ska->ska_work, spl_cache_grow_work, ska);
|
|
|
|
schedule_delayed_work(&ska->ska_work, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2012-10-29 23:51:59 +00: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-07 23:59:50 +00:00
|
|
|
*/
|
2012-10-29 23:51:59 +00: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-07 21:24:17 +00:00
|
|
|
|
2012-10-29 23:51:59 +00:00
|
|
|
rc = -ENOMEM;
|
2012-09-07 21:24:17 +00: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-07 23:59:50 +00:00
|
|
|
|
|
|
|
SRETURN(rc);
|
2008-02-26 20:36:04 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00: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-07 23:59:50 +00: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 04:54:49 +00: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-07 23:59:50 +00:00
|
|
|
static void *
|
2008-06-25 20:57:45 +00:00
|
|
|
spl_cache_refill(spl_kmem_cache_t *skc, spl_kmem_magazine_t *skm, int flags)
|
2008-02-26 20:36:04 +00:00
|
|
|
{
|
2008-06-26 19:49:42 +00: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-07 23:59:50 +00:00
|
|
|
int count = 0, rc, refill;
|
|
|
|
void *obj = NULL;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-06-26 19:49:42 +00: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 17:18:15 +00:00
|
|
|
spin_lock(&skc->skc_lock);
|
2008-06-27 21:40:11 +00:00
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
while (refill > 0) {
|
2009-01-31 04:54:49 +00:00
|
|
|
/* No slabs available we may need to grow the cache */
|
2008-06-25 20:57:45 +00:00
|
|
|
if (list_empty(&skc->skc_partial_list)) {
|
|
|
|
spin_unlock(&skc->skc_lock);
|
2008-06-27 21:40:11 +00: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-07 23:59:50 +00: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 18:55:37 +00:00
|
|
|
SGOTO(out, rc);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
|
|
|
/* Rescheduled to different CPU skm is not local */
|
|
|
|
if (skm != skc->skc_mag[smp_processor_id()])
|
2010-07-20 18:55:37 +00:00
|
|
|
SGOTO(out, rc);
|
2008-06-26 19:49:42 +00:00
|
|
|
|
|
|
|
/* Potentially rescheduled to the same CPU but
|
2011-10-11 17:11:26 +00:00
|
|
|
* allocations may have occurred from this CPU while
|
2008-06-26 19:49:42 +00:00
|
|
|
* we were sleeping so recalculate max refill. */
|
|
|
|
refill = MIN(refill, skm->skm_size - skm->skm_avail);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
continue;
|
|
|
|
}
|
2008-06-24 17:18:15 +00:00
|
|
|
|
2008-06-25 20:57:45 +00: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 17:18:15 +00:00
|
|
|
|
2008-06-25 20:57:45 +00:00
|
|
|
/* Consume as many objects as needed to refill the requested
|
2008-06-26 19:49:42 +00: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-07 23:59:50 +00:00
|
|
|
while (sks->sks_ref < sks->sks_objs && refill-- > 0 && ++count) {
|
2008-06-26 19:49:42 +00: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-07 23:59:50 +00:00
|
|
|
ASSERT(count < skm->skm_size);
|
2008-06-25 20:57:45 +00:00
|
|
|
skm->skm_objs[skm->skm_avail++]=spl_cache_obj(skc,sks);
|
2008-06-26 19:49:42 +00:00
|
|
|
}
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-06-25 20:57:45 +00: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-13 23:41:06 +00:00
|
|
|
}
|
|
|
|
}
|
2008-06-02 17:28:49 +00:00
|
|
|
|
2008-06-25 20:57:45 +00: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-07 23:59:50 +00:00
|
|
|
SRETURN(NULL);
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* Release an object back to the slab from which it came.
|
|
|
|
*/
|
2008-06-25 20:57:45 +00:00
|
|
|
static void
|
|
|
|
spl_cache_shrink(spl_kmem_cache_t *skc, void *obj)
|
|
|
|
{
|
2008-06-26 19:49:42 +00:00
|
|
|
spl_kmem_slab_t *sks = NULL;
|
2008-06-25 20:57:45 +00:00
|
|
|
spl_kmem_obj_t *sko = NULL;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2008-06-25 20:57:45 +00:00
|
|
|
ASSERT(spin_is_locked(&skc->skc_lock));
|
|
|
|
|
2009-11-13 19:12:43 +00:00
|
|
|
sko = spl_sko_from_obj(skc, obj);
|
2008-07-01 03:28:54 +00:00
|
|
|
ASSERT(sko->sko_magic == SKO_MAGIC);
|
2008-06-25 20:57:45 +00:00
|
|
|
sks = sko->sko_slab;
|
2008-07-01 03:28:54 +00:00
|
|
|
ASSERT(sks->sks_magic == SKS_MAGIC);
|
2008-06-13 23:41:06 +00:00
|
|
|
ASSERT(sks->sks_cache == skc);
|
|
|
|
list_add(&sko->sko_list, &sks->sks_free_list);
|
2008-05-06 20:38:28 +00:00
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
sks->sks_age = jiffies;
|
2008-06-25 20:57:45 +00:00
|
|
|
sks->sks_ref--;
|
2008-06-13 23:41:06 +00:00
|
|
|
skc->skc_obj_alloc--;
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
/* Move slab to skc_partial_list when no longer full. Slabs
|
2008-06-25 20:57:45 +00: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-13 23:41:06 +00:00
|
|
|
list_del(&sks->sks_list);
|
|
|
|
list_add(&sks->sks_list, &skc->skc_partial_list);
|
|
|
|
}
|
2008-02-26 20:36:04 +00:00
|
|
|
|
2011-10-11 17:11:26 +00:00
|
|
|
/* Move empty slabs to the end of the partial list so
|
2008-06-25 20:57:45 +00:00
|
|
|
* they can be easily found and freed during reclamation. */
|
|
|
|
if (sks->sks_ref == 0) {
|
2008-06-13 23:41:06 +00:00
|
|
|
list_del(&sks->sks_list);
|
|
|
|
list_add_tail(&sks->sks_list, &skc->skc_partial_list);
|
|
|
|
skc->skc_slab_alloc--;
|
|
|
|
}
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* Release a batch of objects from a per-cpu magazine back to their
|
|
|
|
* respective slabs. This occurs when we exceed the magazine size,
|
|
|
|
* are under memory pressure, when the cache is idle, or during
|
|
|
|
* cache cleanup. The flush argument contains the number of entries
|
|
|
|
* to remove from the magazine.
|
|
|
|
*/
|
2008-06-25 20:57:45 +00:00
|
|
|
static int
|
|
|
|
spl_cache_flush(spl_kmem_cache_t *skc, spl_kmem_magazine_t *skm, int flush)
|
|
|
|
{
|
|
|
|
int i, count = MIN(flush, skm->skm_avail);
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
|
|
|
ASSERT(skm->skm_magic == SKM_MAGIC);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* XXX: Currently we simply return objects from the magazine to
|
|
|
|
* the slabs in fifo order. The ideal thing to do from a memory
|
|
|
|
* fragmentation standpoint is to cheaply determine the set of
|
|
|
|
* objects in the magazine which will result in the largest
|
|
|
|
* number of free slabs if released from the magazine.
|
|
|
|
*/
|
2008-06-25 20:57:45 +00:00
|
|
|
spin_lock(&skc->skc_lock);
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
spl_cache_shrink(skc, skm->skm_objs[i]);
|
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
skm->skm_avail -= count;
|
|
|
|
memmove(skm->skm_objs, &(skm->skm_objs[count]),
|
2008-06-25 20:57:45 +00:00
|
|
|
sizeof(void *) * skm->skm_avail);
|
|
|
|
|
2008-06-24 17:18:15 +00:00
|
|
|
spin_unlock(&skc->skc_lock);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(count);
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
2009-01-31 04:54:49 +00: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-25 20:57:45 +00:00
|
|
|
void *
|
|
|
|
spl_kmem_cache_alloc(spl_kmem_cache_t *skc, int flags)
|
|
|
|
{
|
|
|
|
spl_kmem_magazine_t *skm;
|
|
|
|
unsigned long irq_flags;
|
|
|
|
void *obj = NULL;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2009-01-31 04:54:49 +00:00
|
|
|
ASSERT(!test_bit(KMC_BIT_DESTROY, &skc->skc_flags));
|
|
|
|
ASSERT(flags & KM_SLEEP);
|
|
|
|
atomic_inc(&skc->skc_ref);
|
2008-06-25 20:57:45 +00:00
|
|
|
local_irq_save(irq_flags);
|
|
|
|
|
|
|
|
restart:
|
|
|
|
/* Safe to update per-cpu structure without lock, but
|
2011-10-11 17:11:26 +00:00
|
|
|
* in the restart case we must be careful to reacquire
|
2008-06-25 20:57:45 +00: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 19:49:42 +00: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-25 20:57:45 +00:00
|
|
|
|
|
|
|
if (likely(skm->skm_avail)) {
|
|
|
|
/* Object available in CPU cache, use it */
|
|
|
|
obj = skm->skm_objs[--skm->skm_avail];
|
2009-01-31 04:54:49 +00:00
|
|
|
skm->skm_age = jiffies;
|
2008-06-25 20:57:45 +00: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-07 23:59:50 +00:00
|
|
|
obj = spl_cache_refill(skc, skm, flags);
|
|
|
|
if (obj == NULL)
|
|
|
|
SGOTO(restart, obj = NULL);
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
local_irq_restore(irq_flags);
|
2008-06-28 05:04:46 +00:00
|
|
|
ASSERT(obj);
|
2009-11-13 19:12:43 +00:00
|
|
|
ASSERT(IS_P2ALIGNED(obj, skc->skc_obj_align));
|
2008-06-25 20:57:45 +00:00
|
|
|
|
|
|
|
/* Pre-emptively migrate object to CPU L1 cache */
|
|
|
|
prefetchw(obj);
|
2009-01-31 04:54:49 +00:00
|
|
|
atomic_dec(&skc->skc_ref);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(obj);
|
2008-06-25 20:57:45 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_alloc);
|
|
|
|
|
2009-01-31 04:54:49 +00: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-25 20:57:45 +00:00
|
|
|
void
|
|
|
|
spl_kmem_cache_free(spl_kmem_cache_t *skc, void *obj)
|
|
|
|
{
|
|
|
|
spl_kmem_magazine_t *skm;
|
|
|
|
unsigned long flags;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2009-01-31 04:54:49 +00: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-07 23:59:50 +00:00
|
|
|
|
|
|
|
/*
|
2012-10-30 18:21:42 +00: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-07 23:59:50 +00:00
|
|
|
*/
|
2012-10-30 18:21:42 +00: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-07 23:59:50 +00:00
|
|
|
|
2008-06-25 20:57:45 +00: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 19:49:42 +00:00
|
|
|
ASSERT(skm->skm_magic == SKM_MAGIC);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
|
|
|
/* Per-CPU cache full, flush it to make space */
|
|
|
|
if (unlikely(skm->skm_avail >= skm->skm_size))
|
|
|
|
(void)spl_cache_flush(skc, skm, skm->skm_refill);
|
|
|
|
|
|
|
|
/* 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-07 23:59:50 +00:00
|
|
|
out:
|
2009-01-31 04:54:49 +00:00
|
|
|
atomic_dec(&skc->skc_ref);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-02-26 20:36:04 +00:00
|
|
|
}
|
2008-06-13 23:41:06 +00:00
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_free);
|
2008-05-09 21:21:33 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
2011-10-11 17:11:26 +00: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 04:54:49 +00: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
|
|
|
|
* is called. The shrinker should return the number of free objects
|
|
|
|
* in the cache when called with nr_to_scan == 0 but not attempt to
|
|
|
|
* free any objects. When nr_to_scan > 0 it is a request that nr_to_scan
|
2012-04-27 22:10:02 +00:00
|
|
|
* objects should be freed, which differs from Solaris semantics.
|
|
|
|
* Solaris semantics are to free all available objects which may (and
|
|
|
|
* probably will) be more objects than the requested nr_to_scan.
|
2009-01-31 04:54:49 +00:00
|
|
|
*/
|
2011-06-16 22:39:08 +00:00
|
|
|
static int
|
|
|
|
__spl_kmem_cache_generic_shrinker(struct shrinker *shrink,
|
|
|
|
struct shrink_control *sc)
|
2008-06-13 23:41:06 +00:00
|
|
|
{
|
2008-06-26 19:49:42 +00:00
|
|
|
spl_kmem_cache_t *skc;
|
2009-01-31 04:54:49 +00:00
|
|
|
int unused = 0;
|
2008-05-09 21:21:33 +00:00
|
|
|
|
2008-06-26 19:49:42 +00:00
|
|
|
down_read(&spl_kmem_cache_sem);
|
2009-01-31 04:54:49 +00:00
|
|
|
list_for_each_entry(skc, &spl_kmem_cache_list, skc_list) {
|
2011-06-16 22:39:08 +00:00
|
|
|
if (sc->nr_to_scan)
|
2012-04-27 22:10:02 +00:00
|
|
|
spl_kmem_cache_reap_now(skc,
|
|
|
|
MAX(sc->nr_to_scan >> fls64(skc->skc_slab_objs), 1));
|
2009-01-31 04:54:49 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Presume everything alloc'ed in reclaimable, this ensures
|
|
|
|
* we are called again with nr_to_scan > 0 so can try and
|
|
|
|
* reclaim. The exact number is not important either so
|
|
|
|
* we forgo taking this already highly contented lock.
|
|
|
|
*/
|
|
|
|
unused += skc->skc_obj_alloc;
|
|
|
|
}
|
2008-06-26 19:49:42 +00:00
|
|
|
up_read(&spl_kmem_cache_sem);
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
return (unused * sysctl_vfs_cache_pressure) / 100;
|
2008-05-09 21:21:33 +00:00
|
|
|
}
|
|
|
|
|
2011-06-16 22:39:08 +00:00
|
|
|
SPL_SHRINKER_CALLBACK_WRAPPER(spl_kmem_cache_generic_shrinker);
|
|
|
|
|
2009-01-31 04:54:49 +00: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 17:28:49 +00:00
|
|
|
void
|
2012-04-27 22:10:02 +00:00
|
|
|
spl_kmem_cache_reap_now(spl_kmem_cache_t *skc, int count)
|
2008-06-02 17:28:49 +00:00
|
|
|
{
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-26 19:49:42 +00:00
|
|
|
|
|
|
|
ASSERT(skc->skc_magic == SKC_MAGIC);
|
2009-01-31 04:54:49 +00:00
|
|
|
ASSERT(!test_bit(KMC_BIT_DESTROY, &skc->skc_flags));
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/* Prevent concurrent cache reaping when contended */
|
|
|
|
if (test_and_set_bit(KMC_BIT_REAPING, &skc->skc_flags)) {
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2009-01-31 04:54:49 +00:00
|
|
|
return;
|
|
|
|
}
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
atomic_inc(&skc->skc_ref);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2012-05-01 21:27:29 +00: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-25 20:57:45 +00:00
|
|
|
|
2012-04-27 19:43:49 +00:00
|
|
|
/* Reclaim from the cache, ignoring it's age and delay. */
|
|
|
|
spl_slab_reclaim(skc, count, 1);
|
2009-01-31 04:54:49 +00:00
|
|
|
clear_bit(KMC_BIT_REAPING, &skc->skc_flags);
|
2012-11-05 21:54:20 +00:00
|
|
|
smp_mb__after_clear_bit();
|
|
|
|
wake_up_bit(&skc->skc_flags, KMC_BIT_REAPING);
|
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
atomic_dec(&skc->skc_ref);
|
2008-06-25 20:57:45 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-06-02 17:28:49 +00:00
|
|
|
}
|
2008-06-13 23:41:06 +00:00
|
|
|
EXPORT_SYMBOL(spl_kmem_cache_reap_now);
|
2008-06-02 17:28:49 +00:00
|
|
|
|
2009-01-31 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* Reap all free slabs from all registered caches.
|
|
|
|
*/
|
2008-02-27 19:09:51 +00:00
|
|
|
void
|
2008-06-13 23:41:06 +00:00
|
|
|
spl_kmem_reap(void)
|
2008-04-21 17:29:47 +00:00
|
|
|
{
|
2011-06-16 22:39:08 +00:00
|
|
|
struct shrink_control sc;
|
|
|
|
|
|
|
|
sc.nr_to_scan = KMC_REAP_CHUNK;
|
|
|
|
sc.gfp_mask = GFP_KERNEL;
|
|
|
|
|
|
|
|
__spl_kmem_cache_generic_shrinker(NULL, &sc);
|
2008-02-26 20:36:04 +00:00
|
|
|
}
|
2008-06-13 23:41:06 +00:00
|
|
|
EXPORT_SYMBOL(spl_kmem_reap);
|
2008-03-18 04:56:43 +00:00
|
|
|
|
2008-06-27 21:40:11 +00:00
|
|
|
#if defined(DEBUG_KMEM) && defined(DEBUG_KMEM_TRACKING)
|
2008-05-09 22:53:20 +00:00
|
|
|
static char *
|
2008-06-25 20:57:45 +00:00
|
|
|
spl_sprintf_addr(kmem_debug_t *kd, char *str, int len, int min)
|
2008-05-06 20:38:28 +00:00
|
|
|
{
|
2008-06-26 19:49:42 +00:00
|
|
|
int size = ((len - 1) < kd->kd_size) ? (len - 1) : kd->kd_size;
|
2008-05-06 20:38:28 +00:00
|
|
|
int i, flag = 1;
|
|
|
|
|
|
|
|
ASSERT(str != NULL && len >= 17);
|
2008-06-26 19:49:42 +00:00
|
|
|
memset(str, 0, len);
|
2008-05-06 20:38:28 +00: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 19:49:42 +00: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-06 20:38:28 +00: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 03:28:54 +00:00
|
|
|
static int
|
|
|
|
spl_kmem_init_tracking(struct list_head *list, spinlock_t *lock, int size)
|
|
|
|
{
|
|
|
|
int i;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-07-01 03:28:54 +00:00
|
|
|
|
|
|
|
spin_lock_init(lock);
|
|
|
|
INIT_LIST_HEAD(list);
|
|
|
|
|
|
|
|
for (i = 0; i < size; i++)
|
|
|
|
INIT_HLIST_HEAD(&kmem_table[i]);
|
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(0);
|
2008-07-01 03:28:54 +00:00
|
|
|
}
|
|
|
|
|
2008-06-27 21:40:11 +00:00
|
|
|
static void
|
|
|
|
spl_kmem_fini_tracking(struct list_head *list, spinlock_t *lock)
|
2008-03-18 04:56:43 +00:00
|
|
|
{
|
2008-06-13 23:41:06 +00:00
|
|
|
unsigned long flags;
|
|
|
|
kmem_debug_t *kd;
|
|
|
|
char str[17];
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2008-06-27 21:40:11 +00:00
|
|
|
spin_lock_irqsave(lock, flags);
|
|
|
|
if (!list_empty(list))
|
2008-11-03 21:06:04 +00:00
|
|
|
printk(KERN_WARNING "%-16s %-5s %-16s %s:%s\n", "address",
|
|
|
|
"size", "data", "func", "line");
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2008-06-27 21:40:11 +00:00
|
|
|
list_for_each_entry(kd, list, kd_list)
|
2008-11-03 21:06:04 +00:00
|
|
|
printk(KERN_WARNING "%p %-5d %-16s %s:%d\n", kd->kd_addr,
|
2009-01-20 21:39:35 +00:00
|
|
|
(int)kd->kd_size, spl_sprintf_addr(kd, str, 17, 8),
|
2008-06-13 23:41:06 +00:00
|
|
|
kd->kd_func, kd->kd_line);
|
|
|
|
|
2008-06-27 21:40:11 +00:00
|
|
|
spin_unlock_irqrestore(lock, flags);
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-06-27 21:40:11 +00:00
|
|
|
}
|
|
|
|
#else /* DEBUG_KMEM && DEBUG_KMEM_TRACKING */
|
2008-07-01 03:28:54 +00:00
|
|
|
#define spl_kmem_init_tracking(list, lock, size)
|
2008-06-27 21:40:11 +00:00
|
|
|
#define spl_kmem_fini_tracking(list, lock)
|
|
|
|
#endif /* DEBUG_KMEM && DEBUG_KMEM_TRACKING */
|
|
|
|
|
2009-02-04 23:15:41 +00:00
|
|
|
static void
|
|
|
|
spl_kmem_init_globals(void)
|
|
|
|
{
|
|
|
|
struct zone *zone;
|
|
|
|
|
|
|
|
/* For now all zones are includes, it may be wise to restrict
|
|
|
|
* this to normal and highmem zones if we see problems. */
|
|
|
|
for_each_zone(zone) {
|
|
|
|
|
|
|
|
if (!populated_zone(zone))
|
|
|
|
continue;
|
|
|
|
|
2009-11-10 22:06:57 +00:00
|
|
|
minfree += min_wmark_pages(zone);
|
|
|
|
desfree += low_wmark_pages(zone);
|
|
|
|
lotsfree += high_wmark_pages(zone);
|
2009-02-04 23:15:41 +00:00
|
|
|
}
|
2009-02-05 20:26:34 +00:00
|
|
|
|
|
|
|
/* Solaris default values */
|
2009-05-20 17:08:37 +00:00
|
|
|
swapfs_minfree = MAX(2*1024*1024 >> PAGE_SHIFT, physmem >> 3);
|
|
|
|
swapfs_reserve = MIN(4*1024*1024 >> PAGE_SHIFT, physmem >> 4);
|
2009-02-04 23:15:41 +00:00
|
|
|
}
|
|
|
|
|
2009-02-25 21:20:40 +00:00
|
|
|
/*
|
|
|
|
* Called at module init when it is safe to use spl_kallsyms_lookup_name()
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
spl_kmem_init_kallsyms_lookup(void)
|
|
|
|
{
|
|
|
|
#ifndef HAVE_GET_VMALLOC_INFO
|
|
|
|
get_vmalloc_info_fn = (get_vmalloc_info_t)
|
|
|
|
spl_kallsyms_lookup_name("get_vmalloc_info");
|
2009-03-17 19:16:31 +00:00
|
|
|
if (!get_vmalloc_info_fn) {
|
|
|
|
printk(KERN_ERR "Error: Unknown symbol get_vmalloc_info\n");
|
2009-02-25 21:20:40 +00:00
|
|
|
return -EFAULT;
|
2009-03-17 19:16:31 +00:00
|
|
|
}
|
2009-02-25 21:20:40 +00:00
|
|
|
#endif /* HAVE_GET_VMALLOC_INFO */
|
|
|
|
|
2009-05-20 21:23:13 +00:00
|
|
|
#ifdef HAVE_PGDAT_HELPERS
|
|
|
|
# ifndef HAVE_FIRST_ONLINE_PGDAT
|
2009-02-25 21:20:40 +00:00
|
|
|
first_online_pgdat_fn = (first_online_pgdat_t)
|
|
|
|
spl_kallsyms_lookup_name("first_online_pgdat");
|
2009-03-17 19:16:31 +00:00
|
|
|
if (!first_online_pgdat_fn) {
|
|
|
|
printk(KERN_ERR "Error: Unknown symbol first_online_pgdat\n");
|
2009-02-25 21:20:40 +00:00
|
|
|
return -EFAULT;
|
2009-03-17 19:16:31 +00:00
|
|
|
}
|
2009-05-20 21:23:13 +00:00
|
|
|
# endif /* HAVE_FIRST_ONLINE_PGDAT */
|
2009-02-25 21:20:40 +00:00
|
|
|
|
2009-05-20 21:23:13 +00:00
|
|
|
# ifndef HAVE_NEXT_ONLINE_PGDAT
|
2009-02-25 21:20:40 +00:00
|
|
|
next_online_pgdat_fn = (next_online_pgdat_t)
|
|
|
|
spl_kallsyms_lookup_name("next_online_pgdat");
|
2009-03-17 19:16:31 +00:00
|
|
|
if (!next_online_pgdat_fn) {
|
|
|
|
printk(KERN_ERR "Error: Unknown symbol next_online_pgdat\n");
|
2009-02-25 21:20:40 +00:00
|
|
|
return -EFAULT;
|
2009-03-17 19:16:31 +00:00
|
|
|
}
|
2009-05-20 21:23:13 +00:00
|
|
|
# endif /* HAVE_NEXT_ONLINE_PGDAT */
|
2009-02-25 21:20:40 +00:00
|
|
|
|
2009-05-20 21:23:13 +00:00
|
|
|
# ifndef HAVE_NEXT_ZONE
|
2009-02-25 21:20:40 +00:00
|
|
|
next_zone_fn = (next_zone_t)
|
|
|
|
spl_kallsyms_lookup_name("next_zone");
|
2009-03-17 19:16:31 +00:00
|
|
|
if (!next_zone_fn) {
|
|
|
|
printk(KERN_ERR "Error: Unknown symbol next_zone\n");
|
2009-02-25 21:20:40 +00:00
|
|
|
return -EFAULT;
|
2009-03-17 19:16:31 +00:00
|
|
|
}
|
2009-05-20 21:23:13 +00:00
|
|
|
# endif /* HAVE_NEXT_ZONE */
|
|
|
|
|
|
|
|
#else /* HAVE_PGDAT_HELPERS */
|
|
|
|
|
|
|
|
# ifndef HAVE_PGDAT_LIST
|
2009-05-20 22:30:13 +00:00
|
|
|
pgdat_list_addr = *(struct pglist_data **)
|
2009-05-20 21:23:13 +00:00
|
|
|
spl_kallsyms_lookup_name("pgdat_list");
|
|
|
|
if (!pgdat_list_addr) {
|
|
|
|
printk(KERN_ERR "Error: Unknown symbol pgdat_list\n");
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
# endif /* HAVE_PGDAT_LIST */
|
|
|
|
#endif /* HAVE_PGDAT_HELPERS */
|
2009-02-25 21:20:40 +00:00
|
|
|
|
2009-07-28 22:06:42 +00:00
|
|
|
#if defined(NEED_GET_ZONE_COUNTS) && !defined(HAVE_GET_ZONE_COUNTS)
|
2009-02-25 21:20:40 +00:00
|
|
|
get_zone_counts_fn = (get_zone_counts_t)
|
|
|
|
spl_kallsyms_lookup_name("get_zone_counts");
|
2009-03-17 19:16:31 +00:00
|
|
|
if (!get_zone_counts_fn) {
|
|
|
|
printk(KERN_ERR "Error: Unknown symbol get_zone_counts\n");
|
2009-02-25 21:20:40 +00:00
|
|
|
return -EFAULT;
|
2009-03-17 19:16:31 +00:00
|
|
|
}
|
2009-07-28 22:06:42 +00:00
|
|
|
#endif /* NEED_GET_ZONE_COUNTS && !HAVE_GET_ZONE_COUNTS */
|
2009-02-25 21:20:40 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* It is now safe to initialize the global tunings which rely on
|
|
|
|
* the use of the for_each_zone() macro. This macro in turns
|
|
|
|
* depends on the *_pgdat symbols which are now available.
|
|
|
|
*/
|
|
|
|
spl_kmem_init_globals();
|
|
|
|
|
2011-12-21 22:22:45 +00:00
|
|
|
#if !defined(HAVE_INVALIDATE_INODES) && !defined(HAVE_INVALIDATE_INODES_CHECK)
|
2011-02-23 20:25:45 +00:00
|
|
|
invalidate_inodes_fn = (invalidate_inodes_t)
|
2011-04-18 20:47:43 +00:00
|
|
|
spl_kallsyms_lookup_name("invalidate_inodes");
|
2011-02-23 20:25:45 +00:00
|
|
|
if (!invalidate_inodes_fn) {
|
|
|
|
printk(KERN_ERR "Error: Unknown symbol invalidate_inodes\n");
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
2011-12-21 22:22:45 +00:00
|
|
|
#endif /* !HAVE_INVALIDATE_INODES && !HAVE_INVALIDATE_INODES_CHECK */
|
2011-02-23 20:25:45 +00:00
|
|
|
|
2011-03-31 00:44:35 +00:00
|
|
|
#ifndef HAVE_SHRINK_DCACHE_MEMORY
|
2011-11-10 00:31:03 +00:00
|
|
|
/* When shrink_dcache_memory_fn == NULL support is disabled */
|
2011-03-31 00:44:35 +00:00
|
|
|
shrink_dcache_memory_fn = (shrink_dcache_memory_t)
|
2011-11-10 00:31:03 +00:00
|
|
|
spl_kallsyms_lookup_name("shrink_dcache_memory");
|
2011-03-31 00:44:35 +00:00
|
|
|
#endif /* HAVE_SHRINK_DCACHE_MEMORY */
|
|
|
|
|
|
|
|
#ifndef HAVE_SHRINK_ICACHE_MEMORY
|
2011-11-10 00:31:03 +00:00
|
|
|
/* When shrink_icache_memory_fn == NULL support is disabled */
|
2011-03-31 00:44:35 +00:00
|
|
|
shrink_icache_memory_fn = (shrink_icache_memory_t)
|
2011-11-10 00:31:03 +00:00
|
|
|
spl_kallsyms_lookup_name("shrink_icache_memory");
|
2011-03-31 00:44:35 +00:00
|
|
|
#endif /* HAVE_SHRINK_ICACHE_MEMORY */
|
|
|
|
|
2009-02-25 21:20:40 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-07-01 03:28:54 +00:00
|
|
|
int
|
|
|
|
spl_kmem_init(void)
|
|
|
|
{
|
|
|
|
int rc = 0;
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-07-01 03:28:54 +00:00
|
|
|
|
|
|
|
init_rwsem(&spl_kmem_cache_sem);
|
|
|
|
INIT_LIST_HEAD(&spl_kmem_cache_list);
|
|
|
|
|
2011-03-23 22:45:55 +00:00
|
|
|
spl_register_shrinker(&spl_kmem_cache_shrinker);
|
2008-07-01 03:28:54 +00:00
|
|
|
|
|
|
|
#ifdef DEBUG_KMEM
|
2009-12-04 23:54:12 +00:00
|
|
|
kmem_alloc_used_set(0);
|
|
|
|
vmem_alloc_used_set(0);
|
2008-07-01 03:28:54 +00:00
|
|
|
|
|
|
|
spl_kmem_init_tracking(&kmem_list, &kmem_lock, KMEM_TABLE_SIZE);
|
|
|
|
spl_kmem_init_tracking(&vmem_list, &vmem_lock, VMEM_TABLE_SIZE);
|
|
|
|
#endif
|
2010-07-20 18:55:37 +00:00
|
|
|
SRETURN(rc);
|
2008-07-01 03:28:54 +00:00
|
|
|
}
|
|
|
|
|
2008-06-27 21:40:11 +00:00
|
|
|
void
|
|
|
|
spl_kmem_fini(void)
|
|
|
|
{
|
|
|
|
#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-04 23:54:12 +00:00
|
|
|
if (kmem_alloc_used_read() != 0)
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-06-16 22:57:04 +00:00
|
|
|
"kmem leaked %ld/%ld bytes\n",
|
|
|
|
kmem_alloc_used_read(), kmem_alloc_max);
|
2008-06-27 21:40:11 +00:00
|
|
|
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2009-12-04 23:54:12 +00:00
|
|
|
if (vmem_alloc_used_read() != 0)
|
2010-07-20 18:55:37 +00:00
|
|
|
SDEBUG_LIMIT(SD_CONSOLE | SD_WARNING,
|
2010-06-16 22:57:04 +00:00
|
|
|
"vmem leaked %ld/%ld bytes\n",
|
|
|
|
vmem_alloc_used_read(), vmem_alloc_max);
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2008-06-27 21:40:11 +00:00
|
|
|
spl_kmem_fini_tracking(&kmem_list, &kmem_lock);
|
|
|
|
spl_kmem_fini_tracking(&vmem_list, &vmem_lock);
|
|
|
|
#endif /* DEBUG_KMEM */
|
2010-07-20 18:55:37 +00:00
|
|
|
SENTRY;
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2011-03-23 22:45:55 +00:00
|
|
|
spl_unregister_shrinker(&spl_kmem_cache_shrinker);
|
2008-06-13 23:41:06 +00:00
|
|
|
|
2010-07-20 18:55:37 +00:00
|
|
|
SEXIT;
|
2008-03-18 04:56:43 +00:00
|
|
|
}
|