linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-raid@vger.kernel.org,
	Chris Leech <christopher.leech@intel.com>,
	"Grover, Andrew" <andrew.grover@intel.com>,
	Deepak Saxena <dsaxena@plexity.net>
Subject: Re: [RFC][PATCH 001 of 3] MD Acceleration: Base ADMA interface
Date: Fri, 3 Feb 2006 11:19:59 +0300	[thread overview]
Message-ID: <20060203081958.GC3434@2ka.mipt.ru> (raw)
In-Reply-To: <1138929154.20036.43.camel@dwillia2-linux.ch.intel.com>

Trivial locking comment.
Selected functions below (adma_queue_desc() and adma_run()) protects
list of descriptor manipulations by only simple lock.
If it is possible to queue descriptors from interrupt/bh context,
locking should be changed.

On Thu, Feb 02, 2006 at 06:12:34PM -0700, Dan Williams (dan.j.williams@intel.com) wrote:

> +/* add descriptor to the process list and conditionally initiate operations */
> +void adma_queue_desc(adma_desc_t *desc, int wake)
> +{
> +	adma_engine_t *eng = desc->engine;
> +
> +	spin_lock(&eng->lock);
> +	list_add_tail(&desc->chain, &eng->desc_chain);
> +	atomic_inc(&eng->ops_pending);

This counter is never used actually...

> +	spin_unlock(&eng->lock);
> +
> +	if (wake) adma_wakeup_thread(eng->thread);
> +
> +	dump_desc(desc);
> +}

...

> +
> +/*
> + * This thread churns through the descriptor chain
> + * Runs the command and if necessary calls the callback function.
> + * Note: This thread makes pio_adma_engine assumptions for now
> + */
> +void adma_run(adma_engine_t *eng)
> +{
> +	adma_desc_t *desc, *prev_desc;
> +	int op = 0;
> +
> +	while(1) {
> +		struct list_head *first;
> +
> +		spin_lock(&eng->lock);
> +		if (list_empty(&eng->desc_chain))
> +			break;
> +
> +		first = eng->desc_chain.next;
> +
> +		/* will be used to satisfy ordering requirements for adma
> +		 * engines that process copy and xor operatations on different
> +		 * channels 
> +		 */ 
> +		prev_desc = op++ ? desc : NULL;
> +		desc = list_entry(first, adma_desc_t, chain);
> +		dump_desc(desc);
> +
> +		list_del_init(first);
> +
> +		atomic_dec(&eng->ops_pending);
> +		spin_unlock(&eng->lock);


If ops_pending could be used as engine's reference counter, it should
not be dropped here, but it looks like it is unused.

> +		switch(desc->command) {
> +			case ADMA_COPY:
> +				eng->cpy_op(desc->buf[0], desc->buf[1], desc->len);
> +				break;
> +			case ADMA_SET:
> +				eng->set_block_op(desc->sources, desc->len, desc->buf, desc->pattern);
> +				break;
> +			case ADMA_COMPARE:
> +				if (eng->cmp_op(desc->buf[0], 
> +				    desc->buf[1], 
> +				    desc->len))
> +					set_bit(ADMA_STAT_CMP, &desc->flags);
> +				else
> +					clear_bit(ADMA_STAT_CMP, &desc->flags);
> +				break;
> +			case ADMA_XOR:
> +				eng->xor_block_op(desc->sources, desc->len, desc->buf);
> +				break;
> +			case ADMA_PQXOR:
> +				printk("%s: Error ADMA_PQXOR not yet implemented\n", __FUNCTION__);
> +				BUG();
> +				break;
> +		}
> +		adma_check_status(desc);
> +
> +		if(desc->callback)
> +			desc->callback(desc, desc->args);
> +		else if(test_bit(ADMA_AUTO_REAP, &desc->flags)) {
> +			BUG_ON(desc->args != NULL);
> +			adma_put_desc(desc);
> +		}
> +	}
> +	spin_unlock(&eng->lock);
> +}
> +
> +static int adma_thread(void * arg)
> +{
> +	adma_thread_t *thread = arg;
> +
> +	/*
> +	 * This thread handles:
> +	 *	> issuing descriptors to an adma engine
> +	 *	> maintaining order between dependent operations
> +	 *	> garbage collecting descriptor resources (upon request)
> +	 *	> running the pio version of an operation when underlying
> +	 *	  hardware support is not present
> +	 */
> +
> +	allow_signal(SIGKILL);
> +	while (!kthread_should_stop()) {
> +
> +		/* We need to wait INTERRUPTIBLE so that
> +		 * we don't add to the load-average.
> +		 * That means we need to be sure no signals are
> +		 * pending
> +		 */
> +		if (signal_pending(current))
> +			flush_signals(current);
> +
> +		wait_event_interruptible_timeout
> +			(thread->wqueue,
> +			 test_bit(THREAD_WAKEUP, &thread->flags)
> +			 || kthread_should_stop(),
> +			 thread->timeout);
> +		try_to_freeze();
> +
> +		clear_bit(THREAD_WAKEUP, &thread->flags);
> +
> +		thread->run(thread->eng);
> +	}
> +
> +	return 0;
> +}

-- 
	Evgeniy Polyakov

      parent reply	other threads:[~2006-02-03  8:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-03  1:12 [RFC][PATCH 001 of 3] MD Acceleration: Base ADMA interface Dan Williams
2006-02-03  8:11 ` Evgeniy Polyakov
2006-02-03 23:58   ` Dan Williams
2006-02-04  8:06     ` Evgeniy Polyakov
2006-02-03  8:19 ` Evgeniy Polyakov [this message]

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=20060203081958.GC3434@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=andrew.grover@intel.com \
    --cc=christopher.leech@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dsaxena@plexity.net \
    --cc=linux-raid@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).