RE: After memory pressure: can't read from tape anymore

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2 Dec 2010, Desai, Kashyap wrote:

> 
> 
> > -----Original Message-----
> > From: Lukas Kolbe [mailto:lkolbe@xxxxxxxxxxxxxxxxxxxxxxxx]
> > Sent: Wednesday, December 01, 2010 3:10 PM
> > To: Kai Makisara
> > Cc: Boaz Harrosh; linux-scsi@xxxxxxxxxxxxxxx; Desai, Kashyap
> > Subject: Re: After memory pressure: can't read from tape anymore
> > 
> > Am Dienstag, den 30.11.2010, 21:53 +0200 schrieb Kai Makisara:
> > > On Tue, 30 Nov 2010, Boaz Harrosh wrote:
> > 
> > I'm Cc'ing Desay Kashyap from LSI, maybe he can comment on the hardware
> > limitations of the SAS1068E?
> Lukas,
> 
> No. it is not limitation from h/w that " CONFIG_FUSION_MAX_SGE" needs to be 128.
> But our code is written such a way that even if you change it more than 128, it will fall down to 128 again.
> 
> To change this value you need to do below changes in mptbase.h
> 
> --
> -#define MPT_SCSI_SG_DEPTH     CONFIG_FUSION_MAX_SGE
> +#define MPT_SCSI_SG_DEPTH       256
> --
> 
> 128 is good amount for Scatter gather element. This value is standard value for MPT FUSIION, since long.
> 
> This value will be reflect to sg_tablesize and linux scatter-gather module will use this value for creating sg_table for HBA.
> See: " cat /sys/class/scsi_host/host<x>/sg_tablesize"
> 
> If single IO is not able to fit into sg_tablesize, then it will be converted into multiple IOs for Low Layer Drivers(By "scatter-gather" module of linux).
> So I do not see any problem with 
> CONFIG_FUSION_MAX_SGE value.  Our driver internally convert sglist into SGE which understood by LSI H/W.
> 
You can't convert write of one block into multiple IOs. If someone wants 
to write 2 MB blocks, the system must transfer 2 MB in one IO. The choices 
are:

1. Direct I/O from user space. With 4 kB page size, this means that 513 
s/g segments (512 if the user buffer page is aligned) must be used. 
(Unless there is an IOMMU and an API for an ULD to use it.)

2. Use a bounce buffer. Dynamic allocation of the bounce buffer with a 
small number of segments is problematic when the system has been running 
for a long time but the buffer can be allocated when the device is 
detected. (This is problematic if the device is detected at run-time.)

I don't know which alternative is more efficient from the HW point of view 
if both are possible. Do you (or someone else) have any opinion on this?

Kai
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux