--- Ulf Lilleengen <lulf_at_stud.ntnu.no> 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 ((<number of disks>-1)*<stripe size>) plus 2*128KB... *giggle*)... -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.comReceived on Wed Nov 07 2007 - 17:57:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:21 UTC