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

[Mike Christie <michaelc@cs.wisc.edu>]

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.