Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1365313 > unrolled thread
| Started by | js1304@gmail.com |
|---|---|
| First post | 2016-03-28 07:30 +0200 |
| Last post | 2016-03-30 10:30 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH 06/11] mm/slab: don't keep free slabs if free_objects exceeds free_limit js1304@gmail.com - 2016-03-28 07:30 +0200
Re: [PATCH 06/11] mm/slab: don't keep free slabs if free_objects exceeds free_limit Christoph Lameter <cl@linux.com> - 2016-03-29 03:10 +0200
Re: [PATCH 06/11] mm/slab: don't keep free slabs if free_objects exceeds free_limit Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-30 10:30 +0200
| From | js1304@gmail.com |
|---|---|
| Date | 2016-03-28 07:30 +0200 |
| Subject | [PATCH 06/11] mm/slab: don't keep free slabs if free_objects exceeds free_limit |
| Message-ID | <rhxUv-2rs-9@gated-at.bofh.it> |
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Currently, determination to free a slab is done whenever free object is
put into the slab. This has a problem that free slabs are not freed
even if we have free slabs and have more free_objects than free_limit
when processed slab isn't a free slab. This would cause to keep
too much memory in the slab subsystem. This patch try to fix it
by checking number of free object after all free work is done. If there
is free slab at that time, we can free it so we keep free slab as minimal
as possible.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
---
mm/slab.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index b96f381..df11757 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3258,6 +3258,9 @@ static void free_block(struct kmem_cache *cachep, void **objpp,
{
int i;
struct kmem_cache_node *n = get_node(cachep, node);
+ struct page *page;
+
+ n->free_objects += nr_objects;
for (i = 0; i < nr_objects; i++) {
void *objp;
@@ -3270,17 +3273,11 @@ static void free_block(struct kmem_cache *cachep, void **objpp,
check_spinlock_acquired_node(cachep, node);
slab_put_obj(cachep, page, objp);
STATS_DEC_ACTIVE(cachep);
- n->free_objects++;
/* fixup slab chains */
- if (page->active == 0) {
- if (n->free_objects > n->free_limit) {
- n->free_objects -= cachep->num;
- list_add_tail(&page->lru, list);
- } else {
- list_add(&page->lru, &n->slabs_free);
- }
- } else {
+ if (page->active == 0)
+ list_add(&page->lru, &n->slabs_free);
+ else {
/* Unconditionally move a slab to the end of the
* partial list on free - maximum time for the
* other objects to be freed, too.
@@ -3288,6 +3285,14 @@ static void free_block(struct kmem_cache *cachep, void **objpp,
list_add_tail(&page->lru, &n->slabs_partial);
}
}
+
+ while (n->free_objects > n->free_limit && !list_empty(&n->slabs_free)) {
+ n->free_objects -= cachep->num;
+
+ page = list_last_entry(&n->slabs_free, struct page, lru);
+ list_del(&page->lru);
+ list_add(&page->lru, list);
+ }
}
static void cache_flusharray(struct kmem_cache *cachep, struct array_cache *ac)
--
1.9.1
[toc] | [next] | [standalone]
| From | Christoph Lameter <cl@linux.com> |
|---|---|
| Date | 2016-03-29 03:10 +0200 |
| Subject | Re: [PATCH 06/11] mm/slab: don't keep free slabs if free_objects exceeds free_limit |
| Message-ID | <rhQkp-72i-3@gated-at.bofh.it> |
| In reply to | #1365313 |
On Mon, 28 Mar 2016, js1304@gmail.com wrote: > From: Joonsoo Kim <iamjoonsoo.kim@lge.com> > > Currently, determination to free a slab is done whenever free object is > put into the slab. This has a problem that free slabs are not freed > even if we have free slabs and have more free_objects than free_limit There needs to be a better explanation here since I do not get why there is an issue with checking after free if a slab is actually free. > when processed slab isn't a free slab. This would cause to keep > too much memory in the slab subsystem. This patch try to fix it > by checking number of free object after all free work is done. If there > is free slab at that time, we can free it so we keep free slab as minimal > as possible. Ok if we check after free work is done then the number of free slabs may be higher than the limit set and then we free the additional slabs to get down to the limit that was set?
[toc] | [prev] | [next] | [standalone]
| From | Joonsoo Kim <iamjoonsoo.kim@lge.com> |
|---|---|
| Date | 2016-03-30 10:30 +0200 |
| Subject | Re: [PATCH 06/11] mm/slab: don't keep free slabs if free_objects exceeds free_limit |
| Message-ID | <rijFM-2CP-7@gated-at.bofh.it> |
| In reply to | #1365749 |
On Mon, Mar 28, 2016 at 08:03:16PM -0500, Christoph Lameter wrote: > On Mon, 28 Mar 2016, js1304@gmail.com wrote: > > > From: Joonsoo Kim <iamjoonsoo.kim@lge.com> > > > > Currently, determination to free a slab is done whenever free object is > > put into the slab. This has a problem that free slabs are not freed > > even if we have free slabs and have more free_objects than free_limit > > There needs to be a better explanation here since I do not get why there > is an issue with checking after free if a slab is actually free. Okay. Consider following 3 objects free situation. free_limt = 10 nr_free = 9 free(free slab) free(free slab) free(not free slab) If we check it one by one, when nr_free > free_limit (at last free), we cannot free the slab because current slab isn't a free slab. But, if we check it lastly, we can free 1 free slab. I will add more explanation on the next version. > > > when processed slab isn't a free slab. This would cause to keep > > too much memory in the slab subsystem. This patch try to fix it > > by checking number of free object after all free work is done. If there > > is free slab at that time, we can free it so we keep free slab as minimal > > as possible. > > Ok if we check after free work is done then the number of free slabs may > be higher than the limit set and then we free the additional slabs to get > down to the limit that was set? Yes. Thanks.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web