Ang: Re: [Stgt-devel] Re: [Iscsitarget-devel] stgt a new version of iscsi target?

Mike Christie michaelc at
Sat Dec 10 19:19:50 CET 2005

Vladislav Bolkhovitin wrote:
> Mike Christie wrote:
>>>> There is still memory and scatterlist allocations. If we are not 
>>>> going to allocate all the memory for a command buffer and request 
>>>> with GFP_ATOMIC (and can then run from the the HW interrupt or soft 
>>>> irq) we have to pass that on to a thread. I guess there is 
>>>> disagreement whether that part is a feature or bad use of GFP_ATOMIC 
>>>> though so... But I just mean to say there could be a little more to do.
>>> Actually, there is the way to allocate sg vectors with buffers in 
>>> SIRQ and not with GFP_ATOMIC. This is the second major improvement, 
>>> which is pending in scst. I called it sgv_pool. This is a new 
>>> allocator in the kernel similar to mem_pool, but it contains 
>>> *complete* sg-vectors of some size with data buffers (pages). 
>>> Initiator sends data requests usually with some fixed size, like 
>>> 128K. After a data command completed, its sg vector will not be 
>>> immediately freed, but will be kept in 
>> We considered this, but what did you decide is the upper limit size 
>> for the pool? Is it dynmaic? We also wanted something that the SCSI 
>> ULDs could use for their allocations which could go up to 6 MB.
> Why do you think it needs any upper limit size? Would you like also any 
> upper limits on sizes of the page or slab caches? I don't see any 

Considering I have not seen the code and am probably misunderstanding 
what you wrote above, I will shutup and wait until it is out to see it.

This email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
Iscsitarget-devel mailing list
Iscsitarget-devel at

More information about the stgt mailing list