Re: scsi: fix sense_slab/bio swapping livelock

Re: scsi: fix sense_slab/bio swapping livelock

[Boaz Harrosh]

On Mon, Apr 07 2008 at 12:52 +0300, Pekka J Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Boaz,
> 
> On Mon, 7 Apr 2008, Boaz Harrosh wrote:
>> The slub behavior described above is disturbing. If I want a 128-byte kmalloc I
>> would use kmalloc. But if I want a dedicated kmem_cache of my own I take the trouble
>> to create one. As I understood it, a dedicated kmem_cache is somewhat growing but
>> lazy-shrinking and eventually maxes out to my usage of it. If I reserve one elemnt then
>> even when memory is low and caches are shrunk I have at least a page. But more then
>> In low memory condition, in a steady sate the cost of each allocation is kept low
>> because I have the pages for my self and I don't need to go grabbing global locks.
>> Sharing with other pools breaks that behavior. Perhaps we need a flag in kmem_cache
>> creation that says we do not want slab sharing (OK slub sharing in this case).
> 
> I think you're better off using the page allocator then. SLOB, for 
> example, doesn't guarantee you're the only user of a page for 
> kmem_cache_alloc() either and I don't really see why it should as it tries 
> to be as memory efficient as possible.
> 
> 		Pekka

Please forgive my ignorance, but what is then the difference between kmem_cache_alloc()
and kmalloc?

would you not agree that sometimes we want to override that sharing of SLOBs?

Boaz

Re: scsi: fix sense_slab/bio swapping livelock

[Pekka Enberg]

Hi Boaz,

On Mon, Apr 7, 2008 at 1:07 PM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>  Please forgive my ignorance, but what is then the difference between kmem_cache_alloc()
>  and kmalloc?

Constructors, user-defined alignment, and tighter object packing.

On Mon, Apr 7, 2008 at 1:07 PM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>  would you not agree that sometimes we want to override that sharing of SLOBs?

To be honest, I really don't quite understand your use-case. But as
far as I can tell, it hasn't never been explicitly guaranteed and most
certainly has not been true since the merging of SLOB and more
recently SLUB.

                Pekka