On Saturday 03 May 2014 at 22:21:58, Edward Shishkin wrote:
> On 05/03/2014 08:48 PM, Ivan Shapovalov wrote:
> > 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.
>
> This happens in error paths. Don't be so scrupulous ;)
I don't think so:
- wander.c:485
dealloc_tx_list() <- reiser4_write_logs()
- wander.c:505
dealloc_wmap_actor() <- dealloc_wmap() <- reiser4_write_logs()
> Also users will use copy-on-write transaction model for their SSDs(*),
> and in this mode journals are tiny: they contain only system blocks.
> In short, there is nothing to discard..
>
> (*) http://marc.info/?l=reiserfs-devel&m=139449965000686&w=2
>
> >>>>> [...]
> >>>>
> >>>> 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?)
>
> I think, yes: 12 years ago 64-bit archs looked like exotic..
>
> > and there is a place
> >
> > (reiser4_dealloc_blocks_bitmap()) where this convention is apparently
> > broken.
> I suspect that even the author of the bitmap code doesn't know, why it
> is broken ;)
>
> Edward.
>
> > And this is tedious, because public interfaces seem to pass start+len, but
> > in some places it's more convenient to use start+end...
Ok, so I'll follow the convention.
And oh, blocks != sectors... It looks like I really need to make a backup of:
- the last good reiser4.ko
- my /home
--
Ivan Shapovalov / intelfx /Attachment:
signature.asc
Description: This is a digitally signed message part.
