Re: reiser4: discard implementation, pass 2: allocation issues

[Edward Shishkin <edward.shishkin@gmail.com>]

On 06/17/2014 10:47 PM, Ivan Shapovalov wrote:
> On Tuesday 17 June 2014 at 22:31:36, Ivan Shapovalov wrote:	
>> On Tuesday 17 June 2014 at 12:29:53, Edward Shishkin wrote:	
>>> [...]
>>>
>>> Yup.
>>> So, if discard is on, we work with 2 lists (delete_set,
>>> delete_set_for_wander).
>>> If discard is off, we work with one blocknr set..
>> Good. So I'll do roughly following for v5:
>> - rename discard_set_* to block_list_* and split off these definitions
>> - write a family of reiser4_atom_dset_*() (log_deferred, log_immediate,
>>    apply_deferred, merge, init, destroy) which will encapsulate discard/nodiscard
>>    check and operate on correct lists (blocknr_set vs block_list)
>> - call reiser4_atom_dset_{init,destroy,merge}() from respective functions
>> - call reiser4_atom_dset_log_{deferred,immediate}() from reiser4_dealloc_blocks()
>> - call reiser4_atom_dset_apply_deferred() from reiser4_post_commit_hook()
>> - directly manipulate the block lists from discard_atom(), checking that we
>>    indeed have discard enabled
>>
>> Is this OK?
> BTW, with txn_atoms there is a locking idiom involving E_REPEAT loops.
>
> Is it fine to implement a
> current_atom_dset_log_...(...) // E_REPEAT loop inside
> instead of
> atom_dset_log_...(txn_atom* atom, ...)

IMHO it is not needed.

atom = get_current_atom_locked();
atom_dset_{defer, immed}_add_extent(atom, ...); // <-- the loop is here
spin_unlock_atom(atom);