On Tuesday 17 June 2014 at 12:29:53, Edward Shishkin wrote:
>
> On 06/17/2014 12:14 PM, Ivan Shapovalov wrote:
> > On Tuesday 17 June 2014 at 02:37:16, Edward Shishkin wrote:
> >> [...]
> >>
> >> Yup, blocknr sets minimize memory consumption and are unsortable...
> >>
> >> I think that the cleanest option will be using lists (instead of blocknr
> >> sets) for
> >> the delete sets, if the discard is turned on. It will reduce memory
> >> consumption
> >> by 20%. Indeed, every entry in a blocknr_set occupies ~8 bytes (assuming
> >> that everything is pretty fragmented because of txmod=wa), whereas a list
> >> entry occupies 32 bytes (start, length, plus 2 pointers for the link).
> >>
> >> In this option we'll need to join lists (instead of merging blocknr
> >> sets) during
> >> atoms fusion and apply the list (instead of blocknr set) to the COMMIT
> >> BITMAP
> >> at pre_commit_hook(). I think it won't be a problem, since the lists are
> >> simpler
> >> than blocknr sets.
> > That's a neat approach. I think I'll use unions and do the decision at runtime.
>
>
> 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?
--
Ivan Shapovalov / intelfx /Attachment:
signature.asc
Description: This is a digitally signed message part.
