All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Pekka J Enberg <penberg@cs.helsinki.fi>
Cc: Hugh Dickins <hugh@veritas.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Jens Axboe <jens.axboe@oracle.com>,
	Christoph Lameter <clameter@sgi.com>,
	Peter Zijlstra <a.p.ziljstra@chello.nl>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	mpm@selenic.com, linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: scsi: fix sense_slab/bio swapping livelock
Date: Mon, 07 Apr 2008 13:07:34 +0300	[thread overview]
Message-ID: <47F9F266.4090107@panasas.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0804071248110.30814@sbz-30.cs.Helsinki.FI>

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

       reply	other threads:[~2008-04-07 10:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200804062359.m36Nx3lA016774@hera.kernel.org>
     [not found] ` <47F9EAD9.3060103@panasas.com>
     [not found]   ` <Pine.LNX.4.64.0804071248110.30814@sbz-30.cs.Helsinki.FI>
2008-04-07 10:07     ` Boaz Harrosh [this message]
2008-04-07 10:17       ` scsi: fix sense_slab/bio swapping livelock Pekka Enberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47F9F266.4090107@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=a.p.ziljstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hugh@veritas.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.