From: Vladislav Bolkhovitin <vst@xxxxxxxx> Subject: Re: Ang: Re: [Stgt-devel] Re: [Iscsitarget-devel] stgt a new version of iscsi target? Date: Fri, 09 Dec 2005 18:29:57 +0300 > > 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 > sgv_pool until the next request (command) or memory pressure on the > system. So, all subsequent commands will allocate already built vectors. > The first allocations will be done in some thread context. This allows > to allocate huge chunks of memory in SIRQ context as well as save a lot > of CPU power necessary to always build big sg vectors for each command > individually. ibmvscsis code the same thing, though it is mainly for caching dma-mapped pages, I guess. - : 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
