Re: [PATCH] Export symbol ksize()
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 work), nor should they call > ksize(). ksize does not take a kmem_cache pointer and it is mainly used for figuring out how much space kmalloc really allocated for an object. As such its more part of the kmalloc/kfree set of calls than the kmem_cache_* calls. We could add another call kmem_cache_size() for symmetries sake. -- 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
Re: [PATCH] Export symbol ksize()
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. -- 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
Re: [BUG] SLOB breaks Crypto
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 to punish SLOB for the assumptions that SLAB/SLUB > > arbitrarily took up, presumably on an architecture that should have > > specified its own alignment requirements and simply couldn't be bothered. > > Making SLAB redzoning work with arbitrary alignment is another matter > > entirely, and something that should probably be revisited. > > > > Anything that assumes more than BYTES_PER_WORD is simply broken and > > should be reverted. The assumptions are not arbitrary. It is reasonable to assume that structures managed by the slab allocators may contain long long variables and that therefore a unsigned long long alignment is required by the allocator. It is the *compiler* who tells us that long long needs to be aligned at double word boundaries. If an arch does not require long long alignment on double word boundaries then the *compiler* should tell us that and then the allocators will align on word boundaries. -- 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
Re: [PATCH 1/4] mm: Move ARCH_SLAB_MINALIGN and ARCH_KMALLOC_MINALIGN 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
Re: [PATCH 1/4] mm: Move ARCH_SLAB_MINALIGN and ARCH_KMALLOC_MINALIGN to
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 be sizeof(unsigned long), not sizeof(unsigned long long). __alignof__(unsigned long long) SLOB needs to respect that as well otherwise objects are not aligned as required by the compiler. -- 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
Re: [PATCH 6/9] kernel: padata : use this_cpu_ptr per-cpu helper
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/padata.c
> @@ -204,7 +204,7 @@ static struct padata_priv *padata_get_next(struct
> parallel_data *pd)
> goto out;
> }
>
> - queue = per_cpu_ptr(pd->pqueue, smp_processor_id());
> + queue = this_cpu_ptr(pd->pqueue);
> if (queue->cpu_index == next_queue->cpu_index) {
Its simpler to just remove the per_cpu op completely and change the if
statement to
if (this_cpu_read(pd->pqueue->cpu_index) == next_queue->cpu_index))
{
..
--
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
Re: [PATCH v2 5/9] kernel: padata : use this_cpu_read per-cpu helper
On Sat, 3 Nov 2012, Shan Wei wrote:
> - queue = per_cpu_ptr(pd->pqueue, smp_processor_id());
> - if (queue->cpu_index == next_queue->cpu_index) {
> + if (this_cpu_read(pd->pqueue->cpu_index) == next_queue->cpu_index) {
> padata = ERR_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
Re: [PATCH v3 5/9] kernel: padata : use __this_cpu_read per-cpu helper
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://vger.kernel.org/majordomo-info.html
