The preallocation of cdevs is also addressed in my patch set. I'll send it out as soon as I'm at my notebook again.
-Jeff -- Jeff Mahoney (apologies for the top post -- from my mobile) On Aug 17, 2012, at 4:58 PM, "Rob Evers <rev...@redhat.com>" <rev...@redhat.com> wrote: > On 08/17/2012 11:37 AM, James Bottomley wrote: >> On Fri, 2012-08-17 at 10:50 -0400, Rob Evers wrote: >>> Wondering if this would be an acceptable interim solution >>> to increasing the limit on the number of tape drives >>> while http://marc.info/?l=linux-scsi&m=134212042809524&w=2 >>> gets sorted out. >>> >>> Signed-off-by: Rob Evers<rev...@redhat.com> >>> --- >>> drivers/scsi/st.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/scsi/st.h b/drivers/scsi/st.h >>> index b548923..408d24f 100644 >>> --- a/drivers/scsi/st.h >>> +++ b/drivers/scsi/st.h >>> @@ -76,7 +76,7 @@ struct st_modedef { >>> #define ST_MODE_SHIFT (7 - ST_NBR_MODE_BITS) >>> #define ST_MODE_MASK ((ST_NBR_MODES - 1)<< ST_MODE_SHIFT) >>> >>> -#define ST_MAX_TAPES 128 >>> +#define ST_MAX_TAPES 1024 >> This is going to cause an order 2 GFP_ATOMIC allocation (on 64 bit >> platforms) for the contiguous scsi_tapes array ... if large numbers of >> tapes are genuinely required, shouldn't we fix this first and then >> expand the number quite a bit more? >> >> James >> > > Pre allocation of cdevs during init time needs addressing as well > to increase ST_MAX_TAPES quite a bit more, right? > > Would leaving out Lee's sysfs updates out be ok, if ST_MAX_TAPES were > significantly increased? > > Rob > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
