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 1/9] ACPI, APEI, Add ERST record ID cache
Date: Mon, 25 Oct 2010 10:08:27 +0800	[thread overview]
Message-ID: <1287972507.2862.302.camel@yhuang-dev> (raw)
In-Reply-To: <20101022120404.GF10456@basil.fritz.box>

Hi, Andi,

On Fri, 2010-10-22 at 20:04 +0800, Andi Kleen wrote:
> On Wed, Oct 20, 2010 at 09:36:52AM +0800, Huang Ying wrote:
> > 1
> > 			2
> > 3
> > 			4
> > -1
> > 			-1
> > 
> > where -1 signals there is no more record ID.
> > 
> > Reader 1 has no chance to check record 2 and 4, while reader 2 has no
> > chance to check record 1 and 3. And any other GET_NEXT_RECORD_ID will
> > return -1, that is, other readers will has no chance to check any
> > record even they are not cleared by anyone.
> > 
> > This makes raw GET_NEXT_RECORD_ID not suitable for usage of multiple
> > users.
> > 
> > To solve the issue, an in memory ERST record ID cache is designed and
> > implemented. When enumerating record ID, the ID returned by
> > GET_NEXT_RECORD_ID is added into cache in addition to be returned to
> > caller. So other readers can check the cache to get all record ID
> > available.
> 
> Generally it looks ok, just a minor cleanup nit below.
> 
> Reviewed-by: Andi Kleen <ak@linux.intel.com>

Thanks.

> > +static int erst_record_id_cache_add_one(void)
> > +{
> > +	u64 id, prev_id, first_id;
> > +	int i, rc;
> > +	struct erst_record_id_entry *entries;
> > +	unsigned long flags;
> > +
> > +	id = prev_id = first_id = APEI_ERST_INVALID_RECORD_ID;
> > +retry:
> > +	spin_lock_irqsave(&erst_lock, flags);
> > +	rc = __erst_get_next_record_id(&id);
> > +	spin_unlock_irqrestore(&erst_lock, flags);
> > +	if (rc == -ENOENT)
> > +		return 0;
> > +	if (rc)
> > +		return rc;
> > +	if (id == APEI_ERST_INVALID_RECORD_ID)
> > +		return 0;
> > +	/* can not skip current ID, or look back to first ID */
> > +	if (id == prev_id || id == first_id)
> > +		return 0;
> > +	if (first_id == APEI_ERST_INVALID_RECORD_ID)
> > +		first_id = id;
> > +	prev_id = id;
> > +
> > +	entries = erst_record_id_cache.entries;
> > +	for (i = 0; i < erst_record_id_cache.len; i++) {
> > +		if (!entries[i].cleared && entries[i].id == id)
> > +			break;
> > +	}
> > +	/* record id already in cache, try next */
> > +	if (i < erst_record_id_cache.len)
> > +		goto retry;
> > +	if (erst_record_id_cache.len >= erst_record_id_cache.size) {
> > +		int new_size, alloc_size;
> > +		struct erst_record_id_entry *new_entries;
> > +
> > +		new_size = erst_record_id_cache.size * 2;
> > +		new_size = max_t(int, new_size, ERST_RECORD_ID_CACHE_SIZE_MIN);
> > +		new_size = min_t(int, new_size, ERST_RECORD_ID_CACHE_SIZE_MAX);
> 
> This is clamp_t() 

Yes. Will change it.

> > +		if (new_size <= erst_record_id_cache.size) {
> > +			if (printk_ratelimit())
> > +				pr_warning(FW_WARN ERST_PFX
> > +					   "too many record ID!\n");
> > +			return 0;
> > +		}
> > +		alloc_size = new_size * sizeof(struct erst_record_id_entry);
> > +		if (alloc_size < PAGE_SIZE)
> > +			new_entries = kmalloc(alloc_size, GFP_KERNEL);
> > +		else
> > +			new_entries = vmalloc(alloc_size);
> 
> This is essentially kremalloc with vmalloc. Since this a common
> pattern it would be nicer to put a generic helper for this somewhere.

Yes. But will try to do that in another patch.

Best Regards,
Huang Ying



  reply	other threads:[~2010-10-25  2:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-20  1:36 [PATCH 0/9] ACPI, APEI patches for 2.6.37 Huang Ying
2010-10-20  1:36 ` [PATCH 1/9] ACPI, APEI, Add ERST record ID cache Huang Ying
2010-10-22 12:04   ` Andi Kleen
2010-10-25  2:08     ` Huang Ying [this message]
2010-10-20  1:36 ` [PATCH 2/9] Add lock-less version of bitmap_set/clear Huang Ying
2010-10-20  1:36 ` [PATCH 3/9] lock-less NULL terminated single list implementation Huang Ying
2010-10-20  1:36 ` [PATCH 4/9] lock-less general memory allocator Huang Ying
2010-10-20  1:36 ` [PATCH 5/9] Hardware error device core Huang Ying
2010-10-20  1:36 ` [PATCH 6/9] Hardware error record persistent support Huang Ying
2010-10-20  1:36 ` [PATCH 7/9] ACPI, APEI, Use ERST for hardware error persisting before panic Huang Ying
2010-10-20  1:36 ` [PATCH 8/9] ACPI, APEI, Report GHES error record with hardware error device core Huang Ying
2010-10-20  1:37 ` [PATCH 9/9] ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support Huang Ying
2010-10-22 11:57   ` Andi Kleen
2010-10-25  2:03     ` Huang Ying
2010-10-22  5:50 ` [PATCH 0/9] ACPI, APEI patches for 2.6.37 Len Brown
2010-10-22  8:55   ` Huang Ying
2010-10-22 11:57   ` Andi Kleen
2010-10-22 11:59 ` Andi Kleen

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=1287972507.2862.302.camel@yhuang-dev \
    --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.