On Fri, 4 May 2007, Christoph Lameter wrote:
> He is not able to calculate it just using the object size since he does
> not know where the slab put the slab management structure. And in case of
> SLUB there is no slab management structure... Which means he would have to
> special case based on
On Fri, 4 May 2007, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > On Fri, 4 May 2007, Pekka Enberg wrote:
> >
> > > Again, slab has no way of actually estimating how many pages you need for
> > > a
> > > given number of objects. So we end up calculating some upper bound which
> > > doesn't b
On Fri, 4 May 2007, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > SLAB can calculate exactly how many pages are needed. The per cpu and per
> > node stuff is setup at boot and does not change. We are talking about the
> > worst case scenario here. True in case of an off slab
> > we have addit
Christoph Lameter wrote:
On Fri, 4 May 2007, Pekka Enberg wrote:
Again, slab has no way of actually estimating how many pages you need for a
given number of objects. So we end up calculating some upper bound which
doesn't belong in mm/slab.c. I am perfectly okay with:
It can give a worst case
Christoph Lameter wrote:
SLAB can calculate exactly how many pages are needed. The per
cpu and per node stuff is setup at boot and does not change. We are
talking about the worst case scenario here. True in case of an off slab
we have additional overhead that would also have to go into worst cas
On Fri, 4 May 2007, Pekka Enberg wrote:
> Again, slab has no way of actually estimating how many pages you need for a
> given number of objects. So we end up calculating some upper bound which
> doesn't belong in mm/slab.c. I am perfectly okay with:
It can give a worst case number and that is wha
On Fri, 4 May 2007, Pekka Enberg wrote:
> > which would calculate the worst case memory scenario for allocation the
> > number of indicated objects?
>
> IIRC this looks more or less what Peter had initially. I don't like the API
> because there's no way for slab (perhaps this is different for slu
On Fri, 2007-05-04 at 11:30 -0700, Christoph Lameter wrote:
> Hmmm... Maybe lets have
>
> unsigned kmem_estimate_pages(struct kmem_cache *slab_cache, int objects)
>
> which would calculate the worst case memory scenario for allocation the
> number of indicated objects?
On Fri, 4 May 2007, Pete
Christoph Lameter wrote:
Hmmm... Maybe lets have
unsigned kmem_estimate_pages(struct kmem_cache *slab_cache, int objects)
which would calculate the worst case memory scenario for allocation the
number of indicated objects?
IIRC this looks more or less what Peter had initially. I don't like t
On Fri, 2007-05-04 at 11:30 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Peter Zijlstra wrote:
>
> > > Ok so you really need the number of objects per page? If you know the
> > > number of objects then you can calculate the pages needed which would be
> > > the maximum memory needed?
>
On Fri, 4 May 2007, Peter Zijlstra wrote:
> > Ok so you really need the number of objects per page? If you know the
> > number of objects then you can calculate the pages needed which would be
> > the maximum memory needed?
>
> Yes, that would work.
Hmmm... Maybe lets have
unsigned kmem_estim
On Fri, 2007-05-04 at 11:04 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Peter Zijlstra wrote:
>
> > > I could add a function that tells you how many object you could allocate
> > > from a slab without the page allocator becoming involved? It would count
> > > the object slots available
On Fri, 4 May 2007, Peter Zijlstra wrote:
> > I could add a function that tells you how many object you could allocate
> > from a slab without the page allocator becoming involved? It would count
> > the object slots available on the partial slabs.
>
> I need to know how many pages to reserve t
On Fri, 2007-05-04 at 09:36 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Peter Zijlstra wrote:
>
> > Expost buffer_size in order to allow fair estimates on the actual space
> > used/needed.
>
> If its just an estimate that you are after then I think ksize is
> sufficient.
>
> The buff
On Fri, 4 May 2007, Peter Zijlstra wrote:
> Expost buffer_size in order to allow fair estimates on the actual space
> used/needed.
If its just an estimate that you are after then I think ksize is
sufficient.
The buffer size does not include the other per slab overhead that SLAB
needs nor the
On Fri, 2007-05-04 at 09:23 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Peter Zijlstra wrote:
>
> > On Fri, 2007-05-04 at 09:09 -0700, Christoph Lameter wrote:
> > > On Fri, 4 May 2007, Pekka Enberg wrote:
> > >
> > > > On 5/4/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > > > Expo
On Fri, 4 May 2007, Peter Zijlstra wrote:
> On Fri, 2007-05-04 at 09:09 -0700, Christoph Lameter wrote:
> > On Fri, 4 May 2007, Pekka Enberg wrote:
> >
> > > On 5/4/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > > Expost buffer_size in order to allow fair estimates on the actual space
> > >
On Fri, 2007-05-04 at 09:09 -0700, Christoph Lameter wrote:
> On Fri, 4 May 2007, Pekka Enberg wrote:
>
> > On 5/4/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > Expost buffer_size in order to allow fair estimates on the actual space
> > > used/needed.
>
> We already have ksize?
ksize gives
On Fri, 4 May 2007, Pekka Enberg wrote:
> On 5/4/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > Expost buffer_size in order to allow fair estimates on the actual space
> > used/needed.
We already have ksize?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
On 5/4/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
Expost buffer_size in order to allow fair estimates on the actual space
used/needed.
[snip]
#ifdef CONFIG_SLAB_FAIR
-static inline int slab_alloc_rank(gfp_t flags)
+static __always_inline int slab_alloc_rank(gfp_t flags)
{
return
Expost buffer_size in order to allow fair estimates on the actual space
used/needed.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
Cc: Pekka Enberg <[EMAIL PROTECTED]>
---
include/linux/slab.h |2 ++
mm/slab.c| 16 ++--
mm/slob.c| 18 ++
21 matches
Mail list logo
