lkml.org 
[lkml]   [2008]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/7] ide: ide_hwgroup_t.rq doesn't need an ide_lock held
On Fri, Oct 10 2008, Elias Oltmanns wrote:
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Subject: [PATCH] ide: ide_hwgroup_t.rq doesn't need an ide_lock held
> >
> > While at it:
> > - no need to check for hwgroup presence in ide_dump_opcode()
> >
> > Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > ---
> [...]
> > Index: b/drivers/ide/ide-io.c
> > ===================================================================
> > --- a/drivers/ide/ide-io.c
> > +++ b/drivers/ide/ide-io.c
> [...]
> > @@ -274,7 +269,11 @@ static void ide_complete_pm_request (ide
> > drive->dev_flags &= ~IDE_DFLAG_BLOCKED;
> > blk_start_queue(drive->queue);
> > }
> > - HWGROUP(drive)->rq = NULL;
> > + spin_unlock_irqrestore(&ide_lock, flags);
> > +
> > + drive->hwif->hwgroup->rq = NULL;
> > +
> > + spin_lock_irqsave(&ide_lock, flags);
> > if (__blk_end_request(rq, 0, 0))
> > BUG();
> > spin_unlock_irqrestore(&ide_lock, flags);
>
> Is it really an improvement to release the lock here?

And more importantly, is it even safe? What serializes ->rq assignments
and checks without the ide_lock? Looks fishy.

But yes, dropping a lock for an assigment just to regrab it right after
is never a win. There's no contention gain, but possible bouncing
problems.

--
Jens Axboe



\
 
 \ /
  Last update: 2008-10-10 11:05    [W:0.054 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site