| Message ID | yq1eiq46ohz.fsf@sermon.lab.mkp.net (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Fri, Sep 18 2009 at 3:28pm -0400, Martin K. Petersen <martin.petersen@oracle.com> wrote: > >>>>> "Jun'ichi" == Jun'ichi Nomura <j-nomura@ce.jp.nec.com> writes: > > + if (q->limits.max_sectors == 0 || q->limits.max_hw_sectors == 0) > + blk_queue_max_sectors(q, SAFE_MAX_SECTORS); > > I'm really not keen on perpetuating SAFE_MAX_SECTORS for something that > was written in this millennium. > > I'd much rather we just do this, then: > > block: Set max_sectors correctly for stacking devices > > The topology changes unintentionally caused SAFE_MAX_SECTORS to be set > for stacking devices. Set the default limit to BLK_DEF_MAX_SECTORS and > provide SAFE_MAX_SECTORS in blk_queue_make_request() for legacy hw > drivers that depend on the old behavior. > > Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Nice. Avoids the need for a safe queue_limits copy and associated naunce. Acked-by: Mike Snitzer <snitzer@redhat.com> -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Martin K. Petersen wrote: >>>>>> "Jun'ichi" == Jun'ichi Nomura <j-nomura@ce.jp.nec.com> writes: > > + if (q->limits.max_sectors == 0 || q->limits.max_hw_sectors == 0) > + blk_queue_max_sectors(q, SAFE_MAX_SECTORS); > > I'm really not keen on perpetuating SAFE_MAX_SECTORS for something that > was written in this millennium. > > I'd much rather we just do this, then: > > block: Set max_sectors correctly for stacking devices > > The topology changes unintentionally caused SAFE_MAX_SECTORS to be set > for stacking devices. Set the default limit to BLK_DEF_MAX_SECTORS and > provide SAFE_MAX_SECTORS in blk_queue_make_request() for legacy hw > drivers that depend on the old behavior. > > Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> > > --- > > diff --git a/block/blk-settings.c b/block/blk-settings.c > index 83413ff..cd9b730 100644 > --- a/block/blk-settings.c > +++ b/block/blk-settings.c > @@ -111,7 +111,7 @@ void blk_set_default_limits(struct queue_limits *lim) > lim->max_hw_segments = MAX_HW_SEGMENTS; > lim->seg_boundary_mask = BLK_SEG_BOUNDARY_MASK; > lim->max_segment_size = MAX_SEGMENT_SIZE; > - lim->max_sectors = lim->max_hw_sectors = SAFE_MAX_SECTORS; > + lim->max_sectors = lim->max_hw_sectors = BLK_DEF_MAX_SECTORS; Umm, with this, BLK_DEF_MAX_SECTORS becomes upper bound of max_hw_sectors and the values of underlying devices are not propagated to the stacking devices. Is it intended? > lim->logical_block_size = lim->physical_block_size = lim->io_min = 512; > lim->bounce_pfn = (unsigned long)(BLK_BOUNCE_ANY >> PAGE_SHIFT); > lim->alignment_offset = 0; > @@ -164,6 +164,7 @@ void blk_queue_make_request(struct request_queue *q, make_request_fn *mfn) > q->unplug_timer.data = (unsigned long)q; > > blk_set_default_limits(&q->limits); > + blk_queue_max_sectors(q, SAFE_MAX_SECTORS); > > /* > * If the caller didn't supply a lock, fall back to our embedded Thanks,
>>>>> "Jun'ichi" == Jun'ichi Nomura <j-nomura@ce.jp.nec.com> writes:
Jun'ichi> Umm, with this, BLK_DEF_MAX_SECTORS becomes upper bound of
Jun'ichi> max_hw_sectors and the values of underlying devices are not
Jun'ichi> propagated to the stacking devices.
Well, max_sectors is already bounded by this. max_hw_sectors only
really matters for PC commands, so I'm not sure it's a big deal for
DM. But I guess we could set the default max_hw_sectors to -1.
I'm just trying to avoid these scattered if-0-set-it-to-something-else
cases. I'd much rather have the defaults do the right thing.
Martin K. Petersen wrote: >>>>>> "Jun'ichi" == Jun'ichi Nomura <j-nomura@ce.jp.nec.com> writes: > > Jun'ichi> Umm, with this, BLK_DEF_MAX_SECTORS becomes upper bound of > Jun'ichi> max_hw_sectors and the values of underlying devices are not > Jun'ichi> propagated to the stacking devices. > > Well, max_sectors is already bounded by this. max_hw_sectors only > really matters for PC commands, so I'm not sure it's a big deal for > DM. But I guess we could set the default max_hw_sectors to -1. > > I'm just trying to avoid these scattered if-0-set-it-to-something-else > cases. I'd much rather have the defaults do the right thing. I agree with that. I had to do the if-0-set-it-to-something-else to avoid putting unnecessary cap on max_hw_sectors. If we aren't sure, shouldn't we set its default to -1 or putting comments in blk_set_default_limits() at least to avoid possible confusion in future? Thanks, -- Jun'ichi Nomura, NEC Corporation -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
diff --git a/block/blk-settings.c b/block/blk-settings.c index 83413ff..cd9b730 100644 --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -111,7 +111,7 @@ void blk_set_default_limits(struct queue_limits *lim) lim->max_hw_segments = MAX_HW_SEGMENTS; lim->seg_boundary_mask = BLK_SEG_BOUNDARY_MASK; lim->max_segment_size = MAX_SEGMENT_SIZE; - lim->max_sectors = lim->max_hw_sectors = SAFE_MAX_SECTORS; + lim->max_sectors = lim->max_hw_sectors = BLK_DEF_MAX_SECTORS; lim->logical_block_size = lim->physical_block_size = lim->io_min = 512; lim->bounce_pfn = (unsigned long)(BLK_BOUNCE_ANY >> PAGE_SHIFT); lim->alignment_offset = 0; @@ -164,6 +164,7 @@ void blk_queue_make_request(struct request_queue *q, make_request_fn *mfn) q->unplug_timer.data = (unsigned long)q; blk_set_default_limits(&q->limits); + blk_queue_max_sectors(q, SAFE_MAX_SECTORS); /* * If the caller didn't supply a lock, fall back to our embedded