On Fri, 9 Nov 2012, Shan Wei wrote:
> For bottom halves off, __this_cpu_read is better.
Reviewed-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
RR_PTR(-ENODATA);
Reviewed-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 31 Oct 2012, Shan Wei wrote:
> From: Shan Wei
>
>
> Signed-off-by: Shan Wei
> ---
> kernel/padata.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/padata.c b/kernel/padata.c
> index 89fe3d1..70dffe8 100644
> --- a/kernel/padata.c
> +++ b/kernel/pad
On Wed, 19 May 2010, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > Maybe we can consolidate that into slab.h so that the alignment is the
> > same for all allocators?
>
> But we don't want that for SLOB as discussed in the other thread. It really
> wants to
Maybe we can consolidate that into slab.h so that the alignment is the
same for all allocators?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 19 May 2010, Paul Mundt wrote:
> > > So one of two things should happen:
> > >
> > > 1) SLOB conforms to SLAB/SLUB in it's test
> > >
> > > 2) SLAB/SLUB conforms to SLOB in it's test
> > >
> > > And yes this is an either-or, you can't say they are both valid.
> >
> > I don't see any reason
On Tue, 17 Feb 2009, Pekka Enberg wrote:
> Hmm, kmem_cache_size() seems bit pointless to me. For
> kmem_cache_create()'d caches, actual allocated size should be more or
> less optimal with no extra space.
Cacheline alignment and word alignment etc etc can still add some space to
the object.
--
T
On Sun, 15 Feb 2009, Matt Mackall wrote:
> And it -is- a category error. The fact that kmalloc is implemented on
> top of kmem_cache_alloc is an implementation detail that callers should
> not assume. They shouldn't call kfree() on kmem_cache_alloc objects
> (even though it might just happen to wo
