On Friday 02 May 2014 at 20:10:16, Edward Shishkin wrote:
> On 05/02/2014 04:32 PM, Ivan Shapovalov wrote:
> > On Friday 02 May 2014 at 16:07:21, Edward Shishkin wrote:
> >> On 05/02/2014 03:36 PM, Ivan Shapovalov wrote:
> >>> On Friday 02 May 2014 at 13:48:28, Edward Shishkin wrote:
> >>> [...]
> >>
> >> We can perfectly populate different "discard trees" in parallel on
> >> different CPUs.
> >> As to sorting the list: I don't know how to perform it in parallel :)
> >> Default assumptions, that everything is serialized, usually lead to
> >> various
> >> bad-scalable solutions...
> >
> > Ah, now I understand what do you mean. If that's about doing less work
> > under the tmgr mutex,
>
> No. This is about minimizing real time.
> We don't know about mutexes. We want to decide, what is preferable:
> populating trees, or sorting the list. There is a chance that the first will
> be faster in systems with many CPUs, so I suggest to use trees.
> That's all!
OK.. well, I've started with lists anyway. The data structure is (of course)
under an abstraction layer, so we can change it.
>
> > then yes, trees are better than lists.
> >
> > BTW, I've seen that reiser4 releases atom lock before allocating another
> > node for a blocknr_set, and that leads to a "do { } while (ret ==
> > -E_REPEAT)" loop around the blocknr_set_add_extent() calls. Is this the
> > preferred way of attaching a dynamic data structure to an atom?
>
> TBH, I have never looked at the deallocation paths in reiser4: everything
> worked fine there.. BTW, why not to use atom's delete_set to discard things?
> Could you please take a look?
Blocks used for the journal (wander.c) are deallocated without BA_DEFER set
and thus they never hit delete_set. However, we want to discard these.
>
> >>> [...]
> >>
> >> what explanation do you mean?
> >>
> >> Edward.
> >
> > A general explanation of how does it work :)
>
> I think this is because of historical reasons.
> Such good explanation costs a lot of time and efforts.
> Namesys was a small company, we couldn't afford to have a technical writer.
> Hans insisted on good comments in the source code..
But there aren't much comments there. ;)
I'm now coding the last part - bitmap querying - and I've got a question: how
do we pass reiser4_block_nr parameters?
Many places use pointers, but I do not really understand why (to optimize for
stack frame size on 32-bit archs?) and there is a place
(reiser4_dealloc_blocks_bitmap()) where this convention is apparently broken.
And this is tedious, because public interfaces seem to pass start+len, but in
some places it's more convenient to use start+end...
--
Ivan Shapovalov / intelfx /Attachment:
signature.asc
Description: This is a digitally signed message part.
