--- Ulf Lilleengen wrote:
> - Many style(9) issues.
>

Hmm... Would "cb" help? R some function too long? I tried to comply to Pawel's
style, but obviously I deviated from it after some weeks...
Could give me an example of the worst issue?

> - Lack of documentation. There are many small comments, but there is little
> description on top of functions describing their purpose and what they do.
> This makes it hard to get into it for reviewers and other developers.
>

Hmm... Yup...

There r interface functions to the GEOM system: ..._start(), ..._done(),
...._create(), and so on...
Then there r 2 worker threads (one for the graid5 start queue (...worker()) and
one for the graid5 done queue (...workerD()).
The other functions r helper functions...
I could add the function-purpose-comment in PP and then try to merge it to TNG
and TOS...

> - As to the code logic itself I was a bit sceptic about having the malloc
> saving
> queue. Does it really improve performance that much? It's just the sort of
> thing that could easily lead to bugs.
>

Hmm... if I understood correctly, FreeBSD's kernel memory suffers under
fragmentation, if many big mem areas r needed... There might be even a dead
lock, if UFS uses 64kb block size... So I thought it would be a good idea to
avoid those sleeps but "hamster-ing" the big chunks... But I am not sure
anymore, that it improved performance (but performance was the reason for
it)...

> - I also wonder a bit why you use two worker threads, as this also increases
> complexity (but again, does it improve performance to the point that it's
> worth it?).
>

Hmm... I think so... At least on MP boxes, since both threads do some XOR-ing
(worker() uses XOR for writing "full-stripes" (where no read is necessary) and
bcopy; and workerD() uses XOR after the old data/parity has been read)...

> And last but not least: All of this have to be reviewed before going into the
> tree, and there are not many people who can do that right now. However, I
> really like your work and would gladly help improving it.
>

OK... review sounds good... maybe we should concentrate on PP then (it is quite
space (in comparison to TNG but not TOS)+time (in comparison to TOS; maybe in
comparison to TNG, too?) efficient and has a read cache)? Although fluffles
favors TNG, although it is quite nasty (a write request of size 4KB costs 3
full stripes ((-1)*) plus 2*128KB... *giggle*)...

-Arne

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"