Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()
On 2/22/07, Pekka Enberg <[EMAIL PROTECTED]> wrote: So you are only interested in rough estimation of how much many pages you need for a given amount of objects? Why not use ksize() for that then? Uhm, I obviously meant, why not expose obj_size() instead. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()
Hi Peter, On Wed, 2007-02-21 at 17:47 +0200, Pekka Enberg wrote: > So how does this work? You ask the slab allocator how many pages you > need for a given number of objects and then those pages are available > to it via the page allocator? Can other users also dip into those > reserves? On 2/22/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: Everybody (ab)using PF_MEMALLOC or the new __GFP_EMERGENCY. So you are only interested in rough estimation of how much many pages you need for a given amount of objects? Why not use ksize() for that then? Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()
On Wed, 2007-02-21 at 17:47 +0200, Pekka Enberg wrote: > Hi Peter, > > On 2/21/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > Provide a method to calculate the number of pages needed to store a given > > number of slab objects (upper bound when considering possible partial and > > free slabs). > > So how does this work? You ask the slab allocator how many pages you > need for a given number of objects and then those pages are available > to it via the page allocator? Can other users also dip into those > reserves? Everybody (ab)using PF_MEMALLOC or the new __GFP_EMERGENCY. > I would prefer we simply have an API for telling the slab allocator to > keep certain number of pages in a reserve for a cache rather than > exposing internals such as object size to rest of the world. Keeping the free pages in the page allocator is good for the buddy system. Although you could probably implement a reserve interface without actually claiming the pages. However, doing it like so separates the making of the reserve from the actual kmem_cache object, I can just carry a sum of pages around instead of a list of kmem_cache pointers. I calculate a potential reserve, I might never actually commit to making (and using) the reserve. Also, I don't see what internals are exposed, kmem_cache is still private to slab.c. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()
On Wed, 2007-02-21 at 17:47 +0200, Pekka Enberg wrote: Hi Peter, On 2/21/07, Peter Zijlstra [EMAIL PROTECTED] wrote: Provide a method to calculate the number of pages needed to store a given number of slab objects (upper bound when considering possible partial and free slabs). So how does this work? You ask the slab allocator how many pages you need for a given number of objects and then those pages are available to it via the page allocator? Can other users also dip into those reserves? Everybody (ab)using PF_MEMALLOC or the new __GFP_EMERGENCY. I would prefer we simply have an API for telling the slab allocator to keep certain number of pages in a reserve for a cache rather than exposing internals such as object size to rest of the world. Keeping the free pages in the page allocator is good for the buddy system. Although you could probably implement a reserve interface without actually claiming the pages. However, doing it like so separates the making of the reserve from the actual kmem_cache object, I can just carry a sum of pages around instead of a list of kmem_cache pointers. I calculate a potential reserve, I might never actually commit to making (and using) the reserve. Also, I don't see what internals are exposed, kmem_cache is still private to slab.c. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()
Hi Peter, On Wed, 2007-02-21 at 17:47 +0200, Pekka Enberg wrote: So how does this work? You ask the slab allocator how many pages you need for a given number of objects and then those pages are available to it via the page allocator? Can other users also dip into those reserves? On 2/22/07, Peter Zijlstra [EMAIL PROTECTED] wrote: Everybody (ab)using PF_MEMALLOC or the new __GFP_EMERGENCY. So you are only interested in rough estimation of how much many pages you need for a given amount of objects? Why not use ksize() for that then? Pekka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()
On 2/22/07, Pekka Enberg [EMAIL PROTECTED] wrote: So you are only interested in rough estimation of how much many pages you need for a given amount of objects? Why not use ksize() for that then? Uhm, I obviously meant, why not expose obj_size() instead. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()
Hi Peter, On 2/21/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote: Provide a method to calculate the number of pages needed to store a given number of slab objects (upper bound when considering possible partial and free slabs). So how does this work? You ask the slab allocator how many pages you need for a given number of objects and then those pages are available to it via the page allocator? Can other users also dip into those reserves? I would prefer we simply have an API for telling the slab allocator to keep certain number of pages in a reserve for a cache rather than exposing internals such as object size to rest of the world. Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/29] mm: kmem_cache_objs_to_pages()
Provide a method to calculate the number of pages needed to store a given
number of slab objects (upper bound when considering possible partial and
free slabs).
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/slab.h |1 +
mm/slab.c|6 ++
2 files changed, 7 insertions(+)
Index: linux-2.6-git/include/linux/slab.h
===
--- linux-2.6-git.orig/include/linux/slab.h 2007-01-09 11:28:32.0
+0100
+++ linux-2.6-git/include/linux/slab.h 2007-01-09 11:30:16.0 +0100
@@ -43,6 +43,7 @@ typedef struct kmem_cache kmem_cache_t _
*/
void __init kmem_cache_init(void);
extern int slab_is_available(void);
+extern unsigned int kmem_cache_objs_to_pages(struct kmem_cache *, int);
struct kmem_cache *kmem_cache_create(const char *, size_t, size_t,
unsigned long,
Index: linux-2.6-git/mm/slab.c
===
--- linux-2.6-git.orig/mm/slab.c2007-01-09 11:30:00.0 +0100
+++ linux-2.6-git/mm/slab.c 2007-01-09 11:30:16.0 +0100
@@ -4482,3 +4482,9 @@ unsigned int ksize(const void *objp)
return obj_size(virt_to_cache(objp));
}
+
+unsigned int kmem_cache_objs_to_pages(struct kmem_cache *cachep, int nr)
+{
+ return ((nr + cachep->num - 1) / cachep->num) << cachep->gfporder;
+}
+EXPORT_SYMBOL_GPL(kmem_cache_objs_to_pages);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/29] mm: kmem_cache_objs_to_pages()
Provide a method to calculate the number of pages needed to store a given
number of slab objects (upper bound when considering possible partial and
free slabs).
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
include/linux/slab.h |1 +
mm/slab.c|6 ++
2 files changed, 7 insertions(+)
Index: linux-2.6-git/include/linux/slab.h
===
--- linux-2.6-git.orig/include/linux/slab.h 2007-01-09 11:28:32.0
+0100
+++ linux-2.6-git/include/linux/slab.h 2007-01-09 11:30:16.0 +0100
@@ -43,6 +43,7 @@ typedef struct kmem_cache kmem_cache_t _
*/
void __init kmem_cache_init(void);
extern int slab_is_available(void);
+extern unsigned int kmem_cache_objs_to_pages(struct kmem_cache *, int);
struct kmem_cache *kmem_cache_create(const char *, size_t, size_t,
unsigned long,
Index: linux-2.6-git/mm/slab.c
===
--- linux-2.6-git.orig/mm/slab.c2007-01-09 11:30:00.0 +0100
+++ linux-2.6-git/mm/slab.c 2007-01-09 11:30:16.0 +0100
@@ -4482,3 +4482,9 @@ unsigned int ksize(const void *objp)
return obj_size(virt_to_cache(objp));
}
+
+unsigned int kmem_cache_objs_to_pages(struct kmem_cache *cachep, int nr)
+{
+ return ((nr + cachep-num - 1) / cachep-num) cachep-gfporder;
+}
+EXPORT_SYMBOL_GPL(kmem_cache_objs_to_pages);
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages()
Hi Peter, On 2/21/07, Peter Zijlstra [EMAIL PROTECTED] wrote: Provide a method to calculate the number of pages needed to store a given number of slab objects (upper bound when considering possible partial and free slabs). So how does this work? You ask the slab allocator how many pages you need for a given number of objects and then those pages are available to it via the page allocator? Can other users also dip into those reserves? I would prefer we simply have an API for telling the slab allocator to keep certain number of pages in a reserve for a cache rather than exposing internals such as object size to rest of the world. Pekka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
