LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Borislav Petkov <petkovbb@googlemail.com>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH 4/4] ide-tape: remove pipeline-specific code from idetape_add_chrdev_read_request()
Date: Wed, 12 Mar 2008 06:58:03 +0100	[thread overview]
Message-ID: <20080312055803.GD4266@gollum.tnic> (raw)
In-Reply-To: <200803110025.51072.bzolnier@gmail.com>

On Tue, Mar 11, 2008 at 12:25:50AM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 09 March 2008, Borislav Petkov wrote:
> > In order to do away with queueing read requests on the pipeline, several things
> > have to be done:
> > 
> > 1. Do not allocate additional pipeline stages in idetape_init_read() until
> > (tape->nr_stages < max_stages) and do only read operation preparations. As a
> > collateral result, idetape_add_stage_tail() becomes unused so remove it.
> > 
> > 2. Wait for all queued pipeline requests to complete before queueing
> 
> Hmm, but we've just removed all pipeline requests with this patch?

yep, this is me being overly cautious :).

> [ ->first_stage and ->next_stage are always NULL after this patch which makes
>   it possible to remove the rest of (now never executed) code for pipeline
>   support, same for idetape_plug_pipeline() and IDETAPE_FLAG_PIPELINE* flags ]

this'll happen next.

> > the read request's buffer directly thru idetape_queue_rw_tail()
> > 
> > 3. Do next request buffer allocation (tape->merge_stage)
> 
> Isn't idetape_init_read() taking care of 3.?

i wanted to have the whole handling at one place and let _init_read() only
prepare the read. Now we don't allocate any new tape->merge_stage anymore,
which is wrong. Originally, this happened in _init_read(), however, if we do
idetape_queue_rw_tail(), we should alloc the new stage _after_ queueing the
request, which means it cannot happen _init_read() now and should take place
afterwards, i.e. as it was in the original patch, or?

> > Signed-off-by: Borislav Petkov <petkovbb@gmail.com>
> 
> Seems like we can get away with:
> 
> From: Borislav Petkov <petkovbb@googlemail.com>
> Subject: [PATCH 4/4] ide-tape: remove pipeline-specific code from idetape_add_chrdev_read_request()
> 
> In order to do away with queueing read requests on the pipeline, several things
> have to be done:
> 
> 1. Do not allocate additional pipeline stages in idetape_init_read() until
> (tape->nr_stages < max_stages) and do only read operation preparations. As a
> collateral result, idetape_add_stage_tail() becomes unused so remove it.
> 
> 2. Queue the read request's buffer directly thru idetape_queue_rw_tail().
> 
> 3. Remove now unused idetape_kmalloc_stage() and idetape_switch_buffers().
> 
> [bart: simplify the original patch]
> 
> Signed-off-by: Borislav Petkov <petkovbb@gmail.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
>  drivers/ide/ide-tape.c |   96 ++-----------------------------------------------
>  1 file changed, 5 insertions(+), 91 deletions(-)
> 
> Index: b/drivers/ide/ide-tape.c
> ===================================================================
> --- a/drivers/ide/ide-tape.c
> +++ b/drivers/ide/ide-tape.c
> @@ -1586,15 +1586,6 @@ abort:
>  	return NULL;
>  }
>  
> -static idetape_stage_t *idetape_kmalloc_stage(idetape_tape_t *tape)
> -{
> -	debug_log(DBG_PROCS, "Enter %s\n", __func__);
> -
> -	if (tape->nr_stages >= tape->max_stages)
> -		return NULL;
> -	return __idetape_kmalloc_stage(tape, 0, 0);
> -}
> -
>  static int idetape_copy_stage_from_user(idetape_tape_t *tape,
>  		idetape_stage_t *stage, const char __user *buf, int n)
>  {
> @@ -1672,39 +1663,6 @@ static void idetape_init_merge_stage(ide
>  	}
>  }
>  
> -static void idetape_switch_buffers(idetape_tape_t *tape, idetape_stage_t *stage)
> -{
> -	struct idetape_bh *tmp;
> -
> -	tmp = stage->bh;
> -	stage->bh = tape->merge_stage->bh;
> -	tape->merge_stage->bh = tmp;
> -	idetape_init_merge_stage(tape);
> -}
> -
> -/* Add a new stage at the end of the pipeline. */
> -static void idetape_add_stage_tail(ide_drive_t *drive, idetape_stage_t *stage)
> -{
> -	idetape_tape_t *tape = drive->driver_data;
> -	unsigned long flags;
> -
> -	debug_log(DBG_PROCS, "Enter %s\n", __func__);
> -
> -	spin_lock_irqsave(&tape->lock, flags);
> -	stage->next = NULL;
> -	if (tape->last_stage != NULL)
> -		tape->last_stage->next = stage;
> -	else
> -		tape->first_stage = stage;
> -		tape->next_stage  = stage;
> -	tape->last_stage = stage;
> -	if (tape->next_stage == NULL)
> -		tape->next_stage = tape->last_stage;
> -	tape->nr_stages++;
> -	tape->nr_pending_stages++;
> -	spin_unlock_irqrestore(&tape->lock, flags);
> -}
> -
>  /* Install a completion in a pending request and sleep until it is serviced. The
>   * caller should ensure that the request will not be serviced before we install
>   * the completion (usually by disabling interrupts).
> @@ -2228,10 +2186,7 @@ static void idetape_empty_write_pipeline
>  static int idetape_init_read(ide_drive_t *drive, int max_stages)
>  {
>  	idetape_tape_t *tape = drive->driver_data;
> -	idetape_stage_t *new_stage;
> -	struct request rq;
>  	int bytes_read;
> -	u16 blocks = *(u16 *)&tape->caps[12];
>  
>  	/* Initialize read operation */
>  	if (tape->chrdev_dir != IDETAPE_DIR_READ) {
> @@ -2267,21 +2222,7 @@ static int idetape_init_read(ide_drive_t
>  			}
>  		}
>  	}
> -	idetape_init_rq(&rq, REQ_IDETAPE_READ);
> -	rq.sector = tape->first_frame;
> -	rq.nr_sectors = blocks;
> -	rq.current_nr_sectors = blocks;
> -	if (!test_bit(IDETAPE_FLAG_PIPELINE_ERR, &tape->flags) &&
> -	    tape->nr_stages < max_stages) {
> -		new_stage = idetape_kmalloc_stage(tape);
> -		while (new_stage != NULL) {
> -			new_stage->rq = rq;
> -			idetape_add_stage_tail(drive, new_stage);
> -			if (tape->nr_stages >= max_stages)
> -				break;
> -			new_stage = idetape_kmalloc_stage(tape);
> -		}
> -	}
> +
>  	if (!test_bit(IDETAPE_FLAG_PIPELINE_ACTIVE, &tape->flags)) {
>  		if (tape->nr_pending_stages >= 3 * max_stages / 4) {
>  			tape->measure_insert_time = 1;
> @@ -2301,9 +2242,6 @@ static int idetape_init_read(ide_drive_t
>  static int idetape_add_chrdev_read_request(ide_drive_t *drive, int blocks)
>  {
>  	idetape_tape_t *tape = drive->driver_data;
> -	unsigned long flags;
> -	struct request *rq_ptr;
> -	int bytes_read;
>  
>  	debug_log(DBG_PROCS, "Enter %s, %d blocks\n", __func__, blocks);
>  
> @@ -2311,37 +2249,13 @@ static int idetape_add_chrdev_read_reque
>  	if (test_bit(IDETAPE_FLAG_FILEMARK, &tape->flags))
>  		return 0;
>  
> -	/* Wait for the next block to reach the head of the pipeline. */
>  	idetape_init_read(drive, tape->max_stages);
> -	if (tape->first_stage == NULL) {
> -		if (test_bit(IDETAPE_FLAG_PIPELINE_ERR, &tape->flags))
> -			return 0;
> -		return idetape_queue_rw_tail(drive, REQ_IDETAPE_READ, blocks,
> -					tape->merge_stage->bh);
> -	}
> -	idetape_wait_first_stage(drive);
> -	rq_ptr = &tape->first_stage->rq;
> -	bytes_read = tape->blk_size * (rq_ptr->nr_sectors -
> -					rq_ptr->current_nr_sectors);
> -	rq_ptr->nr_sectors = 0;
> -	rq_ptr->current_nr_sectors = 0;
>  
> -	if (rq_ptr->errors == IDETAPE_ERROR_EOD)
> +	if (test_bit(IDETAPE_FLAG_PIPELINE_ERR, &tape->flags))
>  		return 0;
> -	else {
> -		idetape_switch_buffers(tape, tape->first_stage);
> -		if (rq_ptr->errors == IDETAPE_ERROR_FILEMARK)
> -			set_bit(IDETAPE_FLAG_FILEMARK, &tape->flags);
> -		spin_lock_irqsave(&tape->lock, flags);
> -		idetape_remove_stage_head(drive);
> -		spin_unlock_irqrestore(&tape->lock, flags);
> -	}
> -	if (bytes_read > blocks * tape->blk_size) {
> -		printk(KERN_ERR "ide-tape: bug: trying to return more bytes"
> -				" than requested\n");
> -		bytes_read = blocks * tape->blk_size;
> -	}
> -	return (bytes_read);
> +
> +	return idetape_queue_rw_tail(drive, REQ_IDETAPE_READ, blocks,
> +				     tape->merge_stage->bh);
>  }
>  
>  static void idetape_pad_zeros(ide_drive_t *drive, int bcount)

-- 
Regards/Gruß,
    Boris.

  reply	other threads:[~2008-03-12  5:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-09 17:10 [PATCH 0/4] ide-tape: remove pipeline functionality-v2 Borislav Petkov
2008-03-09 17:10 ` [PATCH 1/4] ide-tape: remove tape->cache_stage Borislav Petkov
2008-03-10 23:24   ` Bartlomiej Zolnierkiewicz
2008-03-11  6:40     ` Borislav Petkov
2008-03-09 17:10 ` [PATCH 2/4] ide-tape: remove pipeline-specific code from idetape_add_chrdev_write_request Borislav Petkov
2008-03-10 23:25   ` Bartlomiej Zolnierkiewicz
2008-03-12  5:41     ` Borislav Petkov
2008-03-12 13:51       ` Bartlomiej Zolnierkiewicz
2008-03-12 14:31       ` Bartlomiej Zolnierkiewicz
2008-03-09 17:10 ` [PATCH 3/4] ide-tape remove pipeline speed/control calculations Borislav Petkov
2008-03-10 23:25   ` Bartlomiej Zolnierkiewicz
2008-03-09 17:10 ` [PATCH 4/4] ide-tape: remove pipeline-specific code from idetape_add_chrdev_read_request() Borislav Petkov
2008-03-10 23:25   ` Bartlomiej Zolnierkiewicz
2008-03-12  5:58     ` Borislav Petkov [this message]
2008-03-12 13:51       ` Bartlomiej Zolnierkiewicz
2008-03-13  6:19         ` Borislav Petkov
2008-03-10 23:24 ` [PATCH 0/4] ide-tape: remove pipeline functionality-v2 Bartlomiej Zolnierkiewicz

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=20080312055803.GD4266@gollum.tnic \
    --to=petkovbb@googlemail.com \
    --cc=bzolnier@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petkovbb@gmail.com \
    --subject='Re: [PATCH 4/4] ide-tape: remove pipeline-specific code from idetape_add_chrdev_read_request()' \
    /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

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).