All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Ying <ying.huang@intel.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Len Brown <lenb@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH -v3 2/8] lib, Make gen_pool memory allocator lock-less
Date: Sun, 31 Oct 2010 22:30:36 +0800	[thread overview]
Message-ID: <1288535436.3536.14.camel@yhuang-mobile> (raw)
In-Reply-To: <20101027091741.GD2472@basil.fritz.box>

Hi, Andi,

Sorry for late. In traveling recently.

On Wed, 2010-10-27 at 02:17 -0700, Andi Kleen wrote:
> > --- a/lib/genalloc.c
> > +++ b/lib/genalloc.c
> > @@ -1,8 +1,8 @@
> >  /*
> > - * Basic general purpose allocator for managing special purpose memory
> > - * not managed by the regular kmalloc/kfree interface.
> > - * Uses for this includes on-device special memory, uncached memory
> > - * etc.
> > + * Basic general purpose allocator for managing special purpose
> > + * memory, for example, memory that is not managed by the regular
> > + * kmalloc/kfree interface.  Uses for this includes on-device special
> > + * memory, uncached memory etc.
> 
> I think we need some more description here about the locklessness:
> 
> How about adding to the comment:
> 
> This version of the allocator supports lockless operation.
> 
> This makes it safe to use in NMI handlers and other special unblockable
> contexts that could otherwise deadlock on locks.  This is implemented by 
> using atomic operations and retries on any conflicts. 
> The disadvantage is that there may be livelocks in extreme cases.

Or add something like:

To get better scalability, one allocator can be used for each CPU.

> The lockless operation only works if there is enough memory
> available. If new memory is added to the pool a lock has to 
> be still taken. So any user relying on locklessness has to ensure
> that sufficient memory is preallocated.

In fact, because RCU is used between gen_pool_add and
gen_pool_alloc/gen_pool_free, the memory can be added to pool at any
time. This makes the memory allocator more flexible. Maybe we can add
gen_pool_remove in the future to shrink the preallocated memory at any
time.

> The basic atomic operation of this allocator is cmpxchg on long. 
> On architectures that don't support cmpxchg natively a fallback
> is used. If the fallback uses locks it may not be safe to use
> it in NMI contexts on these architectures.
> 
> > +/**
> > + * gen_pool_for_each_chunk - iterate over chunks of generic memory pool
> > + * @chunk:	the struct gen_pool_chunk * to use as a loop cursor
> > + * @pool:	the generic memory pool
> > + */
> 
> I believe that's not safe in a lockless context right?
> Should note that.

Yes. Will add that.

Best Regards,
Huang Ying



  reply	other threads:[~2010-10-31 14:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-27  5:28 [PATCH -v3 0/8] ACPI, APEI patches for 2.6.37 Huang Ying
2010-10-27  5:28 ` [PATCH -v3 1/8] ACPI, APEI, Add ERST record ID cache Huang Ying
2010-10-27  5:28 ` [PATCH -v3 2/8] lib, Make gen_pool memory allocator lock-less Huang Ying
2010-10-27  9:17   ` Andi Kleen
2010-10-31 14:30     ` Huang Ying [this message]
2010-10-27  5:28 ` [PATCH -v3 3/8] lib, Add lock-less NULL terminated single list Huang Ying
2010-10-27  5:28 ` [PATCH -v3 4/8] Hardware error device core Huang Ying
2010-10-27  5:28 ` [PATCH -v3 5/8] Hardware error record persistent support Huang Ying
2010-10-27  5:28 ` [PATCH -v3 6/8] ACPI, APEI, Use ERST for hardware error persisting before panic Huang Ying
2010-10-27  5:28 ` [PATCH -v3 7/8] ACPI, APEI, Report GHES error record with hardware error device core Huang Ying
2010-10-27  5:28 ` [PATCH -v3 8/8] ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support Huang Ying
2010-10-27 10:07 ` [PATCH -v3 0/8] ACPI, APEI patches for 2.6.37 Peter Zijlstra
2010-10-27 15:27   ` Randy Dunlap
2010-10-31 11:36     ` huang ying
2010-10-31 11:36       ` huang ying
2010-10-27 17:23   ` Andi Kleen
2010-10-28 16:01     ` Ingo Molnar

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=1288535436.3536.14.camel@yhuang-mobile \
    --to=ying.huang@intel.com \
    --cc=andi@firstfloor.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.