On 12/05/2015 01:38 PM, Max Khon wrote:
A full-featured one I agree is too much. But what about a simple one? We
have a greater tolerance for false negatives -- failing to allocate space
even if it's available -- than other allocators because this just means the
cmd has to wait until previous commands complete, instead of failure.
If we had a small, fixed-size array in tcmu_cmd to keep track of its data
area allocation ranges, wouldn't that let us track the ranges it was using
so we could free them in the bitmap on completion[1]? If the allocation
required more ranges than the fixed size, we'd just give up and sleep. Worst
case, once all submitted commands completed we'd know we could satisfy the
next pending one.
Thoughts on this approach?
[1] basically a copy of the iovec[] userspace sees, but safe from userspace
clobbering it.
The problem is that iovec[] size depends on se_cmd scatterlists length
(basically se_cmd->t_bidi_data_nents + se_cmd->t_data_nents).
How big/long these can be?
That's why I tried to re-use scatterlists to keep data ring allocation
information (as I was not quite sure how to keep the information about
variable sized scatterlist in a fixed-size tcmu_cmd).
Do you have any ideas?
iovec[] size does *not* depend on scatterlists length, it depends on how
many contiguous sections of the data area we need. Because we are
copying and consolidating at the same time all the scatterlist buffers
into the data area. With the current circular allocator, iovec len will
usually be 1, and will only be 2 if the data buffer was split across the
end of the data area.
What I was getting at before was that switching to a bitmap allocator to
allow OoO completions will still only require us to keep track of
allocations to the extent the allocations in the data area are
fragmented by OoO completions. For example if I represent 3 cmds using
the data area like this:
AABBCCC...
then B completing OoO leaves:
AA..CCC...
If D needs 5 chunks, we can keep track of this with just 2
(offset,length) entries in its struct tcmu_cmd used-list.
AADDCCCDDD
If we say our used-list in tcmu_cmd is a fixed size of 4, then we only
get in trouble if the data area looks like this:
E.F.G.H.I.
because while we have the room in the data area, we can't remember 5
chunks to free them properly.
I would say it's ok that we fail to allocate for D now, because 1) this
case is pathological and 2) even so the consequence is just that we have
to wait until some cmd finishes, like E:
..F.G.H.I.
then we can continue:
DDFDGDHDI. <-- 4 extents, can represent in used-list[4]
So that's why I was saying we can get away with a simple bitmap
allocator. It's ok if it fails to allocate in pathological cases, and we
know all allocations in the data area are short-lived.
Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
