Ang: Re: [Stgt-devel] Re: [Iscsitarget-devel] stgt a new version of iscsi target?
fujita.tomonori at lab.ntt.co.jp
Sat Dec 10 09:46:56 CET 2005
From: Vladislav Bolkhovitin <vst at vlnb.net>
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
ibmvscsis code the same thing, though it is mainly for caching
dma-mapped pages, I guess.
More information about the stgt